From maoliang.ml at alibaba-inc.com  Tue Sep  1 02:38:15 2020
From: maoliang.ml at alibaba-inc.com (Liang Mao)
Date: Tue, 01 Sep 2020 10:38:15 +0800
Subject: =?UTF-8?B?TG9uZyBwYXVzZSB0aW1lIG9mIEZpbmFsIE1hcmsgaW4gbGF0ZXN0IDExdSBzaGVuYW5kb2Fo?=
Message-ID: <a08e7959-1000-41bf-ba97-6b7b7c9e0f0c.maoliang.ml@alibaba-inc.com>

 Hi Aleksey,
> -----Original Message-----
> From: Aleksey Shipilev [mailto:shade at redhat.com]
> Sent: 2020?9?1? 1:00
> To: Liang Mao <maoliang.ml at alibaba-inc.com>; Roman Kennke
> <rkennke at redhat.com>; shenandoah-dev at openjdk.java.net
> Subject: Re: Long pause time of Final Mark in latest 11u shenandoah
> 
> On 8/31/20 6:31 AM, Liang Mao wrote:
> > Thanks very much for your quick reply! I tried the flush interval but
> > it didn't work. And then I looked into the code and reduced the number
> > of ShenandoahSATBBufferSize which resolved the problem. But now I
> > don't have the testing environment and cannot do more verificatoins. Will let
> you
> > know once I have a double check.
> 
> Ah. Here is the thing: current FlushInterval only works when application comes
> with a full SATB buffer to the filtering code, which can then decide to flush if the
> period had expired. If mutator thread has something in the buffer, but _not_
> anything else -- that would make the thread sit on the hidden elements until
> Final Mark. If you reduce ShenandoahSATBBufferSize, that probably makes
> those low-occupancy buffers submitted to filtering code, where flush deals with
> them.

Yes. I see the force flush only works when the local buffer is full. So reducing the
 buffer size can be a workaround for my case.

> 
> > BTW, do you have any experience of performance impact if we reduce the
> > default value of ShenandoahSATBBufferSize? I guess is it possible
> > that the "snapshots" in Shenandoah would be more than G1 because G1
> > satb only handles old objects?
> 
> SATB handles all reference stores, and it records "previous" values in the fields.
> So it is largely irrelevant if there are "old" or "young" objects. I'd expect the
> same kind of throughput loss as you would do with G1.

IMHO, the large object graph staying in local satb queue could be "floating
 garbage" which is not reached by concurrent marking thread. I guess it would be
 more likely with "young" objects if so.

> 
> Really, the proper way to solve this is to "handshake" the mutator threads
> before finalizing the concurrent mark, and by doing so force them to flush
> however small SATB buffers they sit on.

Ideally it could completely resolve the problem if we could have the handshake
 between mutator threads and marking threads. The concurrent marking thread
will try to notify mutator threads to flush the remaining buffer and the concurrent
marking will eventually stop if there're no more filtered objects. But mutator threads
 may not be running and block the handshake. We may also be able to do a force flush 
of mutator threads' local queue by concurrent marking thread by locks. Or we can
introduce an additional safepoint to flush. Things seems a bit complicated. Do we
 already have a plan for this?


> 
> --
> Thanks,
> -Aleksey

Thanks,
Liang

From shade at redhat.com  Tue Sep  1 11:13:37 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 1 Sep 2020 13:13:37 +0200
Subject: RFR (S) 8252648: Shenandoah: name gang tasks consistently
Message-ID: <e4c4e3ec-26ad-322a-233d-51d5978c120e@redhat.com>

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

Current uses of AbstractGangTask("...") are all over the place, sometimes they are misleading. Need 
to clean this up.

Webrev:
   https://cr.openjdk.java.net/~shade/8252648/webrev.01/

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Tue Sep  1 12:18:16 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 1 Sep 2020 08:18:16 -0400
Subject: RFR (S) 8252648: Shenandoah: name gang tasks consistently
In-Reply-To: <e4c4e3ec-26ad-322a-233d-51d5978c120e@redhat.com>
References: <e4c4e3ec-26ad-322a-233d-51d5978c120e@redhat.com>
Message-ID: <0415daa5-8125-54dd-4e3a-5e7107f490da@redhat.com>

Looks fine to me.

-Zhengyu

On 9/1/20 7:13 AM, Aleksey Shipilev wrote:
> RFE:
>  ? https://bugs.openjdk.java.net/browse/JDK-8252648
> 
> Current uses of AbstractGangTask("...") are all over the place, 
> sometimes they are misleading. Need to clean this up.
> 
> Webrev:
>  ? https://cr.openjdk.java.net/~shade/8252648/webrev.01/
> 
> Testing: hotspot_gc_shenandoah
> 


From shade at redhat.com  Tue Sep  1 13:24:19 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 1 Sep 2020 15:24:19 +0200
Subject: RFR (S) 8252648: Shenandoah: name gang tasks consistently
In-Reply-To: <0415daa5-8125-54dd-4e3a-5e7107f490da@redhat.com>
References: <e4c4e3ec-26ad-322a-233d-51d5978c120e@redhat.com>
 <0415daa5-8125-54dd-4e3a-5e7107f490da@redhat.com>
Message-ID: <86c9b17c-c489-fc72-c720-73803a57e49e@redhat.com>

On 9/1/20 2:18 PM, Zhengyu Gu wrote:
>> Webrev:
>>   ? https://cr.openjdk.java.net/~shade/8252648/webrev.01/

Thank you, pushed.

-- 
-Aleksey


From shade at redhat.com  Tue Sep  1 14:32:41 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 1 Sep 2020 16:32:41 +0200
Subject: Support for SoftMaxHeapSize?
In-Reply-To: <32bc3e88-39e2-774c-4ae5-da932feeb08b@applied-asynchrony.com>
References: <32bc3e88-39e2-774c-4ae5-da932feeb08b@applied-asynchrony.com>
Message-ID: <29dc6eff-33e3-9f97-77d7-a099bf795a61@redhat.com>

On 8/28/20 12:41 PM, Holger Hoffst?tte wrote:
> I've been playing with setting SoftMaxHeapSize for ZGC in order to limit its
> somewhat eager hunger for heap, and it does a really great job while still
> allowing heap expansion for bursty LDS. Would this make sense for Shenandoah as
> well? Compact mode does a great job already, but IMHO some conceptual feature
> parity wouldn't hurt. Only if it's possible and not too much work, obviously. :)

It does not seem to be much work, as we need to do two things: make heuristics target the soft-max 
and teach uncommit code to favor new target when it changes.

Prototyping here:
   https://bugs.openjdk.java.net/browse/JDK-8252660

-- 
Thanks,
-Aleksey


From holger at applied-asynchrony.com  Tue Sep  1 16:06:20 2020
From: holger at applied-asynchrony.com (=?UTF-8?Q?Holger_Hoffst=c3=a4tte?=)
Date: Tue, 1 Sep 2020 18:06:20 +0200
Subject: Support for SoftMaxHeapSize?
In-Reply-To: <29dc6eff-33e3-9f97-77d7-a099bf795a61@redhat.com>
References: <32bc3e88-39e2-774c-4ae5-da932feeb08b@applied-asynchrony.com>
 <29dc6eff-33e3-9f97-77d7-a099bf795a61@redhat.com>
Message-ID: <df8061bc-3788-6434-e44f-42fb930717e8@applied-asynchrony.com>

On 2020-09-01 16:32, Aleksey Shipilev wrote:
> On 8/28/20 12:41 PM, Holger Hoffst?tte wrote:
>> I've been playing with setting SoftMaxHeapSize for ZGC in order to limit its
>> somewhat eager hunger for heap, and it does a really great job while still
>> allowing heap expansion for bursty LDS. Would this make sense for Shenandoah as
>> well? Compact mode does a great job already, but IMHO some conceptual feature
>> parity wouldn't hurt. Only if it's possible and not too much work, obviously. :)
> 
> It does not seem to be much work, as we need to do two things: make
> heuristics target the soft-max and teach uncommit code to favor new
> target when it changes.

Thought so :)

> 
> Prototyping here:
>  ? https://bugs.openjdk.java.net/browse/JDK-8252660
> 

That was quick.. :D

Tried with 14.0.2 (since I still had the tarball), patch applied and built
cleanly. For a quick test I ran eclipse (Shenandoah completely with default
options), opening/building several projects, CDT indexer, plugin updates,
marketplace etc. & watching in JMC.

We can haz pictures: https://imgur.com/a/hW4IYQq

Very nice and (to me) exactly as expected. Thanks!

Holger

From shade at redhat.com  Tue Sep  1 18:55:14 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 1 Sep 2020 20:55:14 +0200
Subject: RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize option
Message-ID: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com>

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

Since JDK 13, there is a SoftMaxHeapSize option that basically instructs GC heuristics to target 
that particular heap size, while leaving the headroom for allocation spikes and other contingencies. 
It makes sense to support this in Shenandoah.

Implementation:
   https://cr.openjdk.java.net/~shade/8252660/webrev.01/

Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah; new tests; adhoc experiments with jcmd

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Sep  1 18:58:20 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 1 Sep 2020 20:58:20 +0200
Subject: Support for SoftMaxHeapSize?
In-Reply-To: <df8061bc-3788-6434-e44f-42fb930717e8@applied-asynchrony.com>
References: <32bc3e88-39e2-774c-4ae5-da932feeb08b@applied-asynchrony.com>
 <29dc6eff-33e3-9f97-77d7-a099bf795a61@redhat.com>
 <df8061bc-3788-6434-e44f-42fb930717e8@applied-asynchrony.com>
Message-ID: <14958533-41aa-832f-b1bc-ef8de7f0f889@redhat.com>

On 9/1/20 6:06 PM, Holger Hoffst?tte wrote:
> We can haz pictures: https://imgur.com/a/hW4IYQq
> Very nice and (to me) exactly as expected. Thanks!

Cool, thanks for testing.

I have a more complete work here:
   https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030776.html

It should now react properly when SoftMaxHeapSize goes down: it should immediately uncommit down to 
new target, without waiting for either uncommit delay, or new GC cycle.

-- 
-Aleksey


From zgu at redhat.com  Wed Sep  2 00:16:30 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 1 Sep 2020 20:16:30 -0400
Subject: RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize
 option
In-Reply-To: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com>
References: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com>
Message-ID: <88a1fe73-0584-de63-0e99-69342e3ebe0d@redhat.com>

Looks fine to me in general.

Tests' @requires are not consistent, some miss  '!vm.graal.enabled'

-Zhengyu

On 9/1/20 2:55 PM, Aleksey Shipilev wrote:
> RFE:
>  ? https://bugs.openjdk.java.net/browse/JDK-8252660
> 
> Since JDK 13, there is a SoftMaxHeapSize option that basically instructs 
> GC heuristics to target that particular heap size, while leaving the 
> headroom for allocation spikes and other contingencies. It makes sense 
> to support this in Shenandoah.
> 
> Implementation:
>  ? https://cr.openjdk.java.net/~shade/8252660/webrev.01/
> 
> Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah; new tests; 
> adhoc experiments with jcmd
> 


From dan.oliveira at outlook.pt  Wed Sep  2 05:22:21 2020
From: dan.oliveira at outlook.pt (Daniel Oliveira)
Date: Wed, 2 Sep 2020 05:22:21 +0000
Subject: Feedback on Shenandoah Memory Performance
In-Reply-To: <AM7PR02MB6081A8F9ADC6C4D0453B653DFF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
References: <AM7PR02MB6081A8F9ADC6C4D0453B653DFF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB60813B80A076348B5C686445FF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>

Hello,
I'm an MSc student making a performance comparison on modern garbage collectors, including Shenandoah. I'm using the default configurations for all collectors (i.e., no explicit tuning) and noticed that the max memory usage with Shenandoah was always 85% of the total heap size (disclaimer, I set the -xms and -xmx as the same value to minimize the effect of runtime resizing, and memory commit hiccups). Looking directly at the GC log, it showed that Shenandoah is only performing GC cycles whenever it reaches that memory ceiling, which makes me think that the GC is ignoring the default InitFreeThreshold (if there is one). Therefore, Shenandoah is not triggering learning collections and always triggering the default MinFreeThreshold (which I assume is 15% of the total heap) to perform GC unconditionally.

To note that latency wise Shenandoah is performing as expected. However, throughput-wise, ZGC is outperforming Shenandoah significantly (5-10%), even for write-intensive workloads. I sent in annex the memory graphs for Shenandoah and ZGC performing the same experiment, and the GC log for Shenandoah. I'm using the JDK 11 version 2018-09-25 (the environment was inherited, so I cannot change it at this stage in the thesis). I would appreciate some feedback on these results because I think they might not be representative of Shenandoah.

Best regards,
Daniel Gon?alves.


From shade at redhat.com  Wed Sep  2 06:37:40 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 2 Sep 2020 08:37:40 +0200
Subject: Feedback on Shenandoah Memory Performance
In-Reply-To: <AM7PR02MB60813B80A076348B5C686445FF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
References: <AM7PR02MB6081A8F9ADC6C4D0453B653DFF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
 <AM7PR02MB60813B80A076348B5C686445FF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
Message-ID: <0ae457d8-fb5a-885b-4cb1-45570edd80ef@redhat.com>

Hi,

On 9/2/20 7:22 AM, Daniel Oliveira wrote:
> Looking directly at the GC log, it showed that Shenandoah
> is only performing GC cycles whenever it reaches that memory ceiling, which makes me think that
> the GC is ignoring the default InitFreeThreshold (if there is one). Therefore, Shenandoah is not
> triggering learning collections and always triggering the default MinFreeThreshold (which I
> assume is 15% of the total heap) to perform GC unconditionally.

Adaptive heuristics should trigger either by allocation rate, or by crossing the min-free threshold. 
It should learn the allocation rate with a few early collections. But since you are using the very 
old build, it might happen that adaptive heuristics did not implement all of that consistently. 
Please try with up-to-date Shenandoah.

> To note that latency wise Shenandoah is performing as expected. However, throughput-wise, ZGC is
> outperforming Shenandoah significantly (5-10%), even for write-intensive workloads. I sent in
> annex the memory graphs for Shenandoah and ZGC performing the same experiment, and the GC log for
> Shenandoah. 

The attachments are scrubbed, can you please resend these to me privately?

> I'm using the JDK 11 version 2018-09-25 (the environment was inherited, so I cannot
> change it at this stage in the thesis). I would appreciate some feedback on these results because
> I think they might not be representative of Shenandoah.

Well, it feels the old build like this is not representative of Shenandoah, because it misses major 
throughput improvements and their backports to 11u: LRB barriers (JDK-8221766), self-fixing barriers 
(JDK-8231087), and the multitude of other minor improvements to both barrier code, optimizations 
around them, and general heuristics goodness.

Note: since we backport a lot of Shenandoah changes to 11u, what is there in 11 GA (I assume that's 
what you have) and what is there in recent 11.0.8+ are very different code bases. Since hardly 
anyone is using old builds, it seems useless to use them for performance comparisons.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Sep  2 07:10:19 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 2 Sep 2020 09:10:19 +0200
Subject: RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize
 option
In-Reply-To: <88a1fe73-0584-de63-0e99-69342e3ebe0d@redhat.com>
References: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com>
 <88a1fe73-0584-de63-0e99-69342e3ebe0d@redhat.com>
Message-ID: <75e1192f-815a-8fae-ce25-0ebb636b549f@redhat.com>

On 9/2/20 2:16 AM, Zhengyu Gu wrote:
> Looks fine to me in general.
> 
> Tests' @requires are not consistent, some miss  '!vm.graal.enabled'

D'oh. That means the test I copy-pasted it from is also inconsistent. I fixed this oddity in new 
tests, and will do another sweep over existing tests in a separate issue.

Updated:
   https://cr.openjdk.java.net/~shade/8252660/webrev.02/

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Sep  2 07:47:10 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 2 Sep 2020 09:47:10 +0200
Subject: RFR (S) 8252695: Shenandoah: clean up Graal enabled/disabled filter
 in tests
Message-ID: <ec735699-914e-6168-a19d-c65ce238c86c@redhat.com>

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

In gc/shenandoah jtreg tests, there are !vm.graal.enabled clauses in some @requires, but not in the 
other. Since JDK 15 and JDK-8249000, we don't need the explicit Graal check in those tests.

But, for consistency within the tests and consistency across the JDK releases, we might consider 
checking for Graal explicitly. This would enable us to transplant the tests from 15u to 11u without 
remembering to check for Graal additionally.

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

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Sep  2 08:00:03 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 2 Sep 2020 10:00:03 +0200
Subject: RFR (S) 8252695: Shenandoah: clean up Graal enabled/disabled
 filter in tests
In-Reply-To: <ec735699-914e-6168-a19d-c65ce238c86c@redhat.com>
References: <ec735699-914e-6168-a19d-c65ce238c86c@redhat.com>
Message-ID: <4b47704e-6085-8083-2f51-d1758fcfbcd4@redhat.com>

On 9/2/20 9:47 AM, Aleksey Shipilev wrote:
> Testbug RFE:
>     https://bugs.openjdk.java.net/browse/JDK-8252695
> 
> In gc/shenandoah jtreg tests, there are !vm.graal.enabled clauses in some @requires, but not in the
> other. Since JDK 15 and JDK-8249000, we don't need the explicit Graal check in those tests.
> 
> But, for consistency within the tests and consistency across the JDK releases, we might consider
> checking for Graal explicitly. This would enable us to transplant the tests from 15u to 11u without
> remembering to check for Graal additionally.
> 
> Fix:
>     https://cr.openjdk.java.net/~shade/8252695/webrev.01/

...or we can do the reverse, and drop the Graal checks (thus relying on JDK-8249000):
   https://cr.openjdk.java.net/~shade/8252695/webrev.02/

This would complicate 11u porting story, but not significantly so, with the upside of not holding 
jdk/jdk tests back because of 11u.

Tell me what you prefer.

-- 
Thanks,
-Aleksey


From aph at redhat.com  Wed Sep  2 08:49:42 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 2 Sep 2020 09:49:42 +0100
Subject: Feedback on Shenandoah Memory Performance
In-Reply-To: <AM7PR02MB60813B80A076348B5C686445FF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
References: <AM7PR02MB6081A8F9ADC6C4D0453B653DFF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
 <AM7PR02MB60813B80A076348B5C686445FF2F0@AM7PR02MB6081.eurprd02.prod.outlook.com>
Message-ID: <5b68d976-db92-25be-0597-2ece25f5162b@redhat.com>

On 02/09/2020 06:22, Daniel Oliveira wrote:

> I'm using the JDK 11 version 2018-09-25 (the environment was
> inherited, so I cannot change it at this stage in the thesis).

Well... I understand the problem, but you're in danger of submitting a
thesis that is out of date before anyone has read it.

-- 
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 zgu at redhat.com  Wed Sep  2 12:41:22 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 2 Sep 2020 08:41:22 -0400
Subject: RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize
 option
In-Reply-To: <75e1192f-815a-8fae-ce25-0ebb636b549f@redhat.com>
References: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com>
 <88a1fe73-0584-de63-0e99-69342e3ebe0d@redhat.com>
 <75e1192f-815a-8fae-ce25-0ebb636b549f@redhat.com>
Message-ID: <5bbdb41f-4377-3b6e-0ec1-bc45733376ed@redhat.com>



On 9/2/20 3:10 AM, Aleksey Shipilev wrote:
> On 9/2/20 2:16 AM, Zhengyu Gu wrote:
>> Looks fine to me in general.
>>
>> Tests' @requires are not consistent, some miss? '!vm.graal.enabled'
> 
> D'oh. That means the test I copy-pasted it from is also inconsistent. I 
> fixed this oddity in new tests, and will do another sweep over existing 
> tests in a separate issue.
> 
> Updated:
>  ? https://cr.openjdk.java.net/~shade/8252660/webrev.02/

Good.

-Zhengyu
> 


From shade at redhat.com  Wed Sep  2 16:41:31 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 2 Sep 2020 18:41:31 +0200
Subject: RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize
 option
In-Reply-To: <5bbdb41f-4377-3b6e-0ec1-bc45733376ed@redhat.com>
References: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com>
 <88a1fe73-0584-de63-0e99-69342e3ebe0d@redhat.com>
 <75e1192f-815a-8fae-ce25-0ebb636b549f@redhat.com>
 <5bbdb41f-4377-3b6e-0ec1-bc45733376ed@redhat.com>
Message-ID: <e143518b-a7da-2063-e348-bfc61cd62a3a@redhat.com>

On 9/2/20 2:41 PM, Zhengyu Gu wrote:
> On 9/2/20 3:10 AM, Aleksey Shipilev wrote:
>> On 9/2/20 2:16 AM, Zhengyu Gu wrote:
>>> Looks fine to me in general.
>>>
>>> Tests' @requires are not consistent, some miss? '!vm.graal.enabled'
>>
>> D'oh. That means the test I copy-pasted it from is also inconsistent. I
>> fixed this oddity in new tests, and will do another sweep over existing
>> tests in a separate issue.
>>
>> Updated:
>>   ? https://cr.openjdk.java.net/~shade/8252660/webrev.02/
> 
> Good.

Thanks, pushed.

-- 
-Aleksey


From adityam at openjdk.java.net  Sun Sep  6 07:10:54 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Sun, 6 Sep 2020 07:10:54 GMT
Subject: RFR: 8250961: Move Universe::update_heap_info_at_gc to CollectedHeap
Message-ID: <M7mmA8k0wOMopPaGMpN_C473ruGq61Wg4jUw-uxrLL0=.11a00df6-9e05-4728-b8b0-5f8d71e57238@github.com>

This is a small refactoring that moves `update_heap_info_at_gc()` and related members to `CollectedHeap`. There should
be no behavioral change.

jdk/hotspot tier1 passed

JBS: https://bugs.openjdk.java.net/browse/JDK-8250961

-------------

Commit messages:
 - 8250961: Move Universe::update_heap_info_at_gc to CollectedHeap

Changes: https://git.openjdk.java.net/jdk/pull/27/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=27&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250961
  Stats: 46 lines in 12 files changed: 16 ins; 20 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/27/head:pull/27

PR: https://git.openjdk.java.net/jdk/pull/27

From gnu.andrew at redhat.com  Mon Sep  7 07:29:46 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 7 Sep 2020 08:29:46 +0100
Subject: [RFR] [8u] 8u272-b06 Upstream Sync
Message-ID: <20200907072946.GF1707023@stopbrexit>

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

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

Changes in aarch64-shenandoah-jdk8u272-b06:
  - JDK-8064319: Need to enable -XX:+TraceExceptions in release builds
  - JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
  - JDK-8144539: Update PKCS11 tests to run with security manager
  - JDK-8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider
  - JDK-8161973: PKIXRevocationChecker.getSoftFailExceptions() not working
  - JDK-8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite
  - JDK-8169925: PKCS #11 Cryptographic Token Interface license
  - JDK-8184762: ZapStackSegments should use optimized memset
  - JDK-8193234: When using -Xcheck:jni an internally allocated buffer can leak
  - JDK-8219919: RuntimeStub name lost with PrintFrameConverterAssembly
  - JDK-8220313: [TESTBUG] Update base image for Docker testing to OL 7.6
  - JDK-8222079: Don't use memset to initialize fields decode_env constructor in disassembler.cpp
  - JDK-8225695: 32-bit build failures after JDK-8080462 (Update SunPKCS11 provider with PKCS11 v2.40 support)
  - JDK-8226575: OperatingSystemMXBean should be made container aware
  - JDK-8226809: Circular reference in printed stack trace is not correctly indented & ambiguous
  - JDK-8228835: Memory leak in PKCS11 provider when using AES GCM
  - JDK-8233621: Mismatch in jsse.enableMFLNExtension property name
  - JDK-8238898: Missing hash characters for header on license file
  - JDK-8243320: Add SSL root certificates to Oracle Root CA program
  - JDK-8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26
  - JDK-8245467: Remove 8u TLSv1.2 implementation files
  - JDK-8245468: Add TLSv1.3 implementation classes from 11.0.7
  - JDK-8245469: Remove DTLS protocol implementation
  - JDK-8245470: Fix JDK8 compatibility issues
  - JDK-8245471: Revert JDK-8148188
  - JDK-8245472: Backport JDK-8038893 to JDK8
  - JDK-8245473: OCSP stapling support
  - JDK-8245474: Add TLS_KRB5 cipher suites support according to RFC-2712
  - JDK-8245476: Disable TLSv1.3 protocol in the ClientHello message by default
  - JDK-8245477: Adjust TLS tests location
  - JDK-8245653: Remove 8u TLS tests
  - JDK-8245681: Add TLSv1.3 regression test from 11.0.7
  - JDK-8251117: Cannot check P11Key size in P11Cipher and P11AEADCipher
  - JDK-8251120: [8u] HotSpot build assumes ENABLE_JFR is set to either true or false
  - JDK-8251341: Minimal Java specification change
  - JDK-8251478: Backport TLSv1.3 regression tests to JDK8u

Main issues of note:
None, clean merge.

diffstat for root
 b/.hgtags            |    1 +
 b/THIRD_PARTY_README |   40 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diffstat for corba
 b/.hgtags            |    1 +
 b/THIRD_PARTY_README |   40 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diffstat for jaxp
 b/.hgtags            |    1 +
 b/THIRD_PARTY_README |   40 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diffstat for jaxws
 b/.hgtags            |    1 +
 b/THIRD_PARTY_README |   40 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diffstat for langtools
 b/.hgtags                                                           |    1 
 b/THIRD_PARTY_README                                                |   40 +++++++++-
 b/src/share/classes/com/sun/tools/javac/resources/legacy.properties |    1 
 b/src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java      |    1 
 4 files changed, 42 insertions(+), 1 deletion(-)

diffstat for nashorn
 b/.hgtags            |    1 +
 b/THIRD_PARTY_README |   40 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diffstat for jdk
 a/src/share/classes/sun/security/ssl/ALPNExtension.java                                                    |  168 
 a/src/share/classes/sun/security/ssl/Alerts.java                                                           |  223 
 a/src/share/classes/sun/security/ssl/AppInputStream.java                                                   |  155 
 a/src/share/classes/sun/security/ssl/AppOutputStream.java                                                  |  150 
 a/src/share/classes/sun/security/ssl/ByteBufferInputStream.java                                            |  187 
 a/src/share/classes/sun/security/ssl/CipherBox.java                                                        | 1089 --
 a/src/share/classes/sun/security/ssl/CipherSuiteList.java                                                  |  181 
 a/src/share/classes/sun/security/ssl/ClientHandshaker.java                                                 | 1812 ----
 a/src/share/classes/sun/security/ssl/DHCrypt.java                                                          |  538 -
 a/src/share/classes/sun/security/ssl/Debug.java                                                            |  201 
 a/src/share/classes/sun/security/ssl/ECDHCrypt.java                                                        |  153 
 a/src/share/classes/sun/security/ssl/EllipticCurvesExtension.java                                          |  388 -
 a/src/share/classes/sun/security/ssl/EllipticPointFormatsExtension.java                                    |  104 
 a/src/share/classes/sun/security/ssl/EngineArgs.java                                                       |  238 
 a/src/share/classes/sun/security/ssl/EngineInputRecord.java                                                |  428 -
 a/src/share/classes/sun/security/ssl/EngineOutputRecord.java                                               |  331 
 a/src/share/classes/sun/security/ssl/EngineWriter.java                                                     |  244 
 a/src/share/classes/sun/security/ssl/ExtensionType.java                                                    |  112 
 a/src/share/classes/sun/security/ssl/HandshakeInStream.java                                                |  232 
 a/src/share/classes/sun/security/ssl/HandshakeMessage.java                                                 | 2061 -----
 a/src/share/classes/sun/security/ssl/HandshakeStateManager.java                                            |  765 --
 a/src/share/classes/sun/security/ssl/Handshaker.java                                                       | 1587 ----
 a/src/share/classes/sun/security/ssl/HelloExtension.java                                                   |   46 
 a/src/share/classes/sun/security/ssl/HelloExtensions.java                                                  |  157 
 a/src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java                                        |  154 
 a/src/share/classes/sun/security/ssl/MAC.java                                                              |  168 
 a/src/share/classes/sun/security/ssl/ProtocolList.java                                                     |  154 
 a/src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java                                       |  115 
 a/src/share/classes/sun/security/ssl/ServerHandshaker.java                                                 | 2062 -----
 a/src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java                                        |  441 -
 a/src/share/classes/sun/security/ssl/UnknownExtension.java                                                 |   60 
 a/src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java                               |  463 -
 a/src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java                                     |  272 
 a/src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h                                            |  124 
 a/test/sun/security/ssl/SessionIdCollisionTest.java                                                        |  158 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java                   |  324 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java                     |  310 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java               |  282 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/CipherSuite/SSL_NULL.java                             |   93 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java                 |  814 --
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java                       |  493 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh                |   81 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java                               |  274 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java                |  289 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java        |  244 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java           |  243 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java                  |  431 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java               |  244 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java                  |  510 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java               |  283 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java              |  275 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java                         |  123 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java         |  323 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java                |  523 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java      |  490 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java                  |  411 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java                |  125 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CheckMethods.java                       |  143 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java                      |  370 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java |  310 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java               |  310 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java                       |  377 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java                 |  323 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java |  261 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java                      |  187 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java    |  272 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java                    |  511 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java            |  564 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CertRequestOverflow.java         |  402 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java                |  361 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java              |  412 -
 a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/Distrust.java           |  273 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/OriginServer.java          |  158 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyAuthTest.java         |  252 
 a/test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ServerIdentityTest.java    |  275 
 a/test/sun/security/ssl/etc/README                                                                         |   94 
 a/test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java                                          |  583 -
 a/test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ComURLNulls.java                                      |  110 
 a/test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java                                  |  290 
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Arrays.java                                        |  294 
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java                                   |  729 -
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java                                |  684 -
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeyEngine.java                             |  274 
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java                                     |  306 
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java                              |  399 -
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java                                   |  480 -
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java                                     |  494 -
 a/test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java                                    |  343 
 a/test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java                             |  383 -
 a/test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java                                |  577 -
 a/test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java                                    |  330 
 a/test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java                                   |  330 
 a/test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java                                     |  441 -
 a/test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java                                           |  424 -
 a/test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java                                           |  447 -
 a/test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java                                         |  247 
 a/test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java                                       |  259 
 a/test/sun/security/ssl/sanity/interop/CipherTest.java                                                     |  591 -
 a/test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java                                           |   59 
 a/test/sun/security/ssl/sanity/interop/JSSEClient.java                                                     |   94 
 a/test/sun/security/ssl/sanity/interop/JSSEServer.java                                                     |   94 
 a/test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java                        |  187 
 a/test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java                     |  318 
 a/test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java                         |  381 -
 a/test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java                        |  350 
 a/test/sun/security/ssl/templates/SSLEngineTemplate.java                                                   |  380 -
 a/test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java                                          |  491 -
 a/test/sun/security/ssl/templates/SSLSocketTemplate.java                                                   |  311 
 b/.hgtags                                                                                                  |    1 
 b/THIRD_PARTY_README                                                                                       |   40 
 b/make/data/cacerts/sslrooteccca                                                                           |   23 
 b/make/data/cacerts/sslrootevrsaca                                                                         |   41 
 b/make/data/cacerts/sslrootrsaca                                                                           |   41 
 b/make/data/checkdeps/refs.allowed                                                                         |   30 
 b/make/mapfiles/libj2pkcs11/mapfile-vers                                                                   |    1 
 b/make/mapfiles/libmanagement/mapfile-vers                                                                 |   12 
 b/src/aix/native/sun/management/AixOperatingSystem.c                                                       |    4 
 b/src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java                                            |   26 
 b/src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java                                          |   25 
 b/src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java                                          |   86 
 b/src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java                                                  |  113 
 b/src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java                                          |  111 
 b/src/share/classes/com/sun/jndi/ldap/ServiceLocator.java                                                  |   25 
 b/src/share/classes/com/sun/jndi/ldap/spi/LdapDnsProvider.java                                             |  109 
 b/src/share/classes/com/sun/jndi/ldap/spi/LdapDnsProviderResult.java                                       |   88 
 b/src/share/classes/com/sun/management/OperatingSystemMXBean.java                                          |    8 
 b/src/share/classes/java/lang/Throwable.java                                                               |    2 
 b/src/share/classes/java/net/SocketPermission.java                                                         |   15 
 b/src/share/classes/java/security/MessageDigest.java                                                       |   15 
 b/src/share/classes/javax/net/ssl/ExtendedSSLSession.java                                                  |    4 
 b/src/share/classes/sun/net/RegisteredDomain.java                                                          |   36 
 b/src/share/classes/sun/security/pkcs11/P11AEADCipher.java                                                 |  752 +
 b/src/share/classes/sun/security/pkcs11/P11Cipher.java                                                     |    4 
 b/src/share/classes/sun/security/pkcs11/P11Digest.java                                                     |   14 
 b/src/share/classes/sun/security/pkcs11/P11PSSSignature.java                                               |  701 +
 b/src/share/classes/sun/security/pkcs11/P11RSACipher.java                                                  |    8 
 b/src/share/classes/sun/security/pkcs11/Secmod.java                                                        |   22 
 b/src/share/classes/sun/security/pkcs11/SunPKCS11.java                                                     |   84 
 b/src/share/classes/sun/security/pkcs11/wrapper/CK_CCM_PARAMS.java                                         |   83 
 b/src/share/classes/sun/security/pkcs11/wrapper/CK_GCM_PARAMS.java                                         |   75 
 b/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java                                          |   55 
 b/src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java                                |  144 
 b/src/share/classes/sun/security/pkcs11/wrapper/Functions.java                                             |  289 
 b/src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java                                                |  118 
 b/src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java                                       |  792 +-
 b/src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java                                       |   16 
 b/src/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java                                 |  179 
 b/src/share/classes/sun/security/provider/certpath/RevocationChecker.java                                  |   13 
 b/src/share/classes/sun/security/ssl/Alert.java                                                            |  297 
 b/src/share/classes/sun/security/ssl/AlpnExtension.java                                                    |  517 +
 b/src/share/classes/sun/security/ssl/Authenticator.java                                                    |  437 -
 b/src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java                                                |   70 
 b/src/share/classes/sun/security/ssl/CertSignAlgsExtension.java                                            |  347 
 b/src/share/classes/sun/security/ssl/CertStatusExtension.java                                              | 1219 +++
 b/src/share/classes/sun/security/ssl/CertificateMessage.java                                               | 1380 +++
 b/src/share/classes/sun/security/ssl/CertificateRequest.java                                               |  951 ++
 b/src/share/classes/sun/security/ssl/CertificateStatus.java                                                |  369 
 b/src/share/classes/sun/security/ssl/CertificateVerify.java                                                | 1180 +++
 b/src/share/classes/sun/security/ssl/ChangeCipherSpec.java                                                 |  252 
 b/src/share/classes/sun/security/ssl/CipherSuite.java                                                      | 2509 ++----
 b/src/share/classes/sun/security/ssl/CipherType.java                                                       |   37 
 b/src/share/classes/sun/security/ssl/Ciphertext.java                                                       |   55 
 b/src/share/classes/sun/security/ssl/ClientAuthType.java                                                   |   36 
 b/src/share/classes/sun/security/ssl/ClientHandshakeContext.java                                           |  110 
 b/src/share/classes/sun/security/ssl/ClientHello.java                                                      | 1157 +++
 b/src/share/classes/sun/security/ssl/ClientKeyExchange.java                                                |  122 
 b/src/share/classes/sun/security/ssl/ConnectionContext.java                                                |   34 
 b/src/share/classes/sun/security/ssl/ContentType.java                                                      |   73 
 b/src/share/classes/sun/security/ssl/CookieExtension.java                                                  |  315 
 b/src/share/classes/sun/security/ssl/DHClientKeyExchange.java                                              |  333 
 b/src/share/classes/sun/security/ssl/DHKeyExchange.java                                                    |  534 +
 b/src/share/classes/sun/security/ssl/DHServerKeyExchange.java                                              |  559 +
 b/src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java                                            |  522 +
 b/src/share/classes/sun/security/ssl/ECDHKeyExchange.java                                                  |  484 +
 b/src/share/classes/sun/security/ssl/ECDHServerKeyExchange.java                                            |  563 +
 b/src/share/classes/sun/security/ssl/ECPointFormatsExtension.java                                          |  300 
 b/src/share/classes/sun/security/ssl/EncryptedExtensions.java                                              |  193 
 b/src/share/classes/sun/security/ssl/EphemeralKeyManager.java                                              |   12 
 b/src/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java                                    |  372 
 b/src/share/classes/sun/security/ssl/Finished.java                                                         | 1113 ++
 b/src/share/classes/sun/security/ssl/HKDF.java                                                             |  186 
 b/src/share/classes/sun/security/ssl/HandshakeAbsence.java                                                 |   42 
 b/src/share/classes/sun/security/ssl/HandshakeConsumer.java                                                |   35 
 b/src/share/classes/sun/security/ssl/HandshakeContext.java                                                 |  560 +
 b/src/share/classes/sun/security/ssl/HandshakeHash.java                                                    |  933 +-
 b/src/share/classes/sun/security/ssl/HandshakeOutStream.java                                               |  197 
 b/src/share/classes/sun/security/ssl/HandshakeProducer.java                                                |   38 
 b/src/share/classes/sun/security/ssl/HelloCookieManager.java                                               |  215 
 b/src/share/classes/sun/security/ssl/HelloRequest.java                                                     |  217 
 b/src/share/classes/sun/security/ssl/InputRecord.java                                                      |  977 --
 b/src/share/classes/sun/security/ssl/JsseJce.java                                                          |   64 
 b/src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java                                            |   11 
 b/src/share/classes/sun/security/ssl/KeyShareExtension.java                                                |  939 ++
 b/src/share/classes/sun/security/ssl/KeyUpdate.java                                                        |  333 
 b/src/share/classes/sun/security/ssl/Krb5Helper.java                                                       |   11 
 b/src/share/classes/sun/security/ssl/Krb5Proxy.java                                                        |    1 
 b/src/share/classes/sun/security/ssl/KrbClientKeyExchange.java                                             |  379 +
 b/src/share/classes/sun/security/ssl/KrbClientKeyExchangeHelper.java                                       |   56 
 b/src/share/classes/sun/security/ssl/KrbKeyExchange.java                                                   |  257 
 b/src/share/classes/sun/security/ssl/MaxFragExtension.java                                                 |  609 +
 b/src/share/classes/sun/security/ssl/NewSessionTicket.java                                                 |  389 +
 b/src/share/classes/sun/security/ssl/OutputRecord.java                                                     |  844 +-
 b/src/share/classes/sun/security/ssl/Plaintext.java                                                        |   79 
 b/src/share/classes/sun/security/ssl/PostHandshakeContext.java                                             |  109 
 b/src/share/classes/sun/security/ssl/PreSharedKeyExtension.java                                            |  892 ++
 b/src/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java                                       |  314 
 b/src/share/classes/sun/security/ssl/ProtocolVersion.java                                                  |  444 -
 b/src/share/classes/sun/security/ssl/PskKeyExchangeModesExtension.java                                     |  332 
 b/src/share/classes/sun/security/ssl/RSAClientKeyExchange.java                                             |  474 -
 b/src/share/classes/sun/security/ssl/RSAKeyExchange.java                                                   |  313 
 b/src/share/classes/sun/security/ssl/RSAServerKeyExchange.java                                             |  339 
 b/src/share/classes/sun/security/ssl/RSASignature.java                                                     |  118 
 b/src/share/classes/sun/security/ssl/RandomCookie.java                                                     |  126 
 b/src/share/classes/sun/security/ssl/Record.java                                                           |  234 
 b/src/share/classes/sun/security/ssl/RenegoInfoExtension.java                                              |  554 +
 b/src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java                                          |  148 
 b/src/share/classes/sun/security/ssl/SSLAlgorithmDecomposer.java                                           |  128 
 b/src/share/classes/sun/security/ssl/SSLAuthentication.java                                                |   31 
 b/src/share/classes/sun/security/ssl/SSLBasicKeyDerivation.java                                            |   81 
 b/src/share/classes/sun/security/ssl/SSLCipher.java                                                        | 2363 ++++++
 b/src/share/classes/sun/security/ssl/SSLConfiguration.java                                                 |  399 +
 b/src/share/classes/sun/security/ssl/SSLConsumer.java                                                      |   35 
 b/src/share/classes/sun/security/ssl/SSLContextImpl.java                                                   |  830 +-
 b/src/share/classes/sun/security/ssl/SSLCredentials.java                                                   |   29 
 b/src/share/classes/sun/security/ssl/SSLEngineImpl.java                                                    | 2642 +-----
 b/src/share/classes/sun/security/ssl/SSLEngineInputRecord.java                                             |  411 +
 b/src/share/classes/sun/security/ssl/SSLEngineOutputRecord.java                                            |  587 +
 b/src/share/classes/sun/security/ssl/SSLExtension.java                                                     |  705 +
 b/src/share/classes/sun/security/ssl/SSLExtensions.java                                                    |  389 +
 b/src/share/classes/sun/security/ssl/SSLHandshake.java                                                     |  547 +
 b/src/share/classes/sun/security/ssl/SSLHandshakeBinding.java                                              |   47 
 b/src/share/classes/sun/security/ssl/SSLKeyAgreement.java                                                  |   32 
 b/src/share/classes/sun/security/ssl/SSLKeyAgreementGenerator.java                                         |   33 
 b/src/share/classes/sun/security/ssl/SSLKeyDerivation.java                                                 |   35 
 b/src/share/classes/sun/security/ssl/SSLKeyDerivationGenerator.java                                        |   34 
 b/src/share/classes/sun/security/ssl/SSLKeyExchange.java                                                   |  633 +
 b/src/share/classes/sun/security/ssl/SSLLogger.java                                                        |  594 +
 b/src/share/classes/sun/security/ssl/SSLMasterKeyDerivation.java                                           |  145 
 b/src/share/classes/sun/security/ssl/SSLPossession.java                                                    |   32 
 b/src/share/classes/sun/security/ssl/SSLPossessionGenerator.java                                           |   30 
 b/src/share/classes/sun/security/ssl/SSLProducer.java                                                      |   33 
 b/src/share/classes/sun/security/ssl/SSLRecord.java                                                        |   93 
 b/src/share/classes/sun/security/ssl/SSLSecretDerivation.java                                              |  152 
 b/src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java                                       |   37 
 b/src/share/classes/sun/security/ssl/SSLServerSocketImpl.java                                              |  335 
 b/src/share/classes/sun/security/ssl/SSLSessionContextImpl.java                                            |   52 
 b/src/share/classes/sun/security/ssl/SSLSessionImpl.java                                                   |  579 +
 b/src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java                                             |   10 
 b/src/share/classes/sun/security/ssl/SSLSocketImpl.java                                                    | 3784 +++-------
 b/src/share/classes/sun/security/ssl/SSLSocketInputRecord.java                                             |  466 +
 b/src/share/classes/sun/security/ssl/SSLSocketOutputRecord.java                                            |  389 +
 b/src/share/classes/sun/security/ssl/SSLStringizer.java                                                    |   41 
 b/src/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java                                          |  303 
 b/src/share/classes/sun/security/ssl/SSLTransport.java                                                     |  202 
 b/src/share/classes/sun/security/ssl/ServerHandshakeContext.java                                           |   82 
 b/src/share/classes/sun/security/ssl/ServerHello.java                                                      | 1502 +++
 b/src/share/classes/sun/security/ssl/ServerHelloDone.java                                                  |  187 
 b/src/share/classes/sun/security/ssl/ServerKeyExchange.java                                                |  123 
 b/src/share/classes/sun/security/ssl/ServerNameExtension.java                                              |  718 +
 b/src/share/classes/sun/security/ssl/SessionId.java                                                        |  108 
 b/src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java                                     |  576 +
 b/src/share/classes/sun/security/ssl/SignatureScheme.java                                                  |  529 +
 b/src/share/classes/sun/security/ssl/StatusResponseManager.java                                            |  963 ++
 b/src/share/classes/sun/security/ssl/SunJSSE.java                                                          |    8 
 b/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java                                            |   50 
 b/src/share/classes/sun/security/ssl/SupportedGroupsExtension.java                                         | 1039 ++
 b/src/share/classes/sun/security/ssl/SupportedVersionsExtension.java                                       |  508 +
 b/src/share/classes/sun/security/ssl/TransportContext.java                                                 |  663 +
 b/src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java                                          |   32 
 b/src/share/classes/sun/security/ssl/TrustStoreManager.java                                                |   52 
 b/src/share/classes/sun/security/ssl/Utilities.java                                                        |  173 
 b/src/share/classes/sun/security/ssl/X509Authentication.java                                               |  337 
 b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java                                               |  144 
 b/src/share/classes/sun/security/ssl/X509TrustManagerImpl.java                                             |  218 
 b/src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java                                               |    2 
 b/src/share/classes/sun/security/ssl/krb5/KrbClientKeyExchangeHelperImpl.java                              |  466 +
 b/src/share/classes/sun/security/util/GCMParameters.java                                                   |  153 
 b/src/share/classes/sun/security/util/HostnameChecker.java                                                 |   94 
 b/src/share/classes/sun/security/util/MessageDigestSpi2.java                                               |   44 
 b/src/share/classes/sun/security/util/RegisteredDomain.java                                                |   93 
 b/src/share/classes/sun/security/util/SecurityConstants.java                                               |    2 
 b/src/share/classes/sun/security/validator/PKIXValidator.java                                              |   72 
 b/src/share/classes/sun/security/validator/SimpleValidator.java                                            |    1 
 b/src/share/classes/sun/security/validator/Validator.java                                                  |   15 
 b/src/share/lib/security/java.security-aix                                                                 |   36 
 b/src/share/lib/security/java.security-linux                                                               |   36 
 b/src/share/lib/security/java.security-macosx                                                              |   36 
 b/src/share/lib/security/java.security-solaris                                                             |   36 
 b/src/share/lib/security/java.security-windows                                                             |   36 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c                                               | 2020 ++---
 b/src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c                                                 |  162 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_digest.c                                                |   53 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_general.c                                               |   27 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c                                               |  284 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c                                                 |    4 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_sign.c                                                  |  225 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_util.c                                                  |  304 
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11.h                                                    |   82 
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11f.h                                                   |  215 
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h                                                   | 1992 +++--
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h                                             |   90 
 b/src/solaris/classes/sun/management/OperatingSystemImpl.java                                              |  129 
 b/src/solaris/native/sun/management/LinuxOperatingSystem.c                                                 |   37 
 b/src/solaris/native/sun/management/MacosxOperatingSystem.c                                                |    4 
 b/src/solaris/native/sun/management/OperatingSystemImpl.c                                                  |   26 
 b/src/solaris/native/sun/management/SolarisOperatingSystem.c                                               |    4 
 b/src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h                                            |    2 
 b/test/TEST.groups                                                                                         |    6 
 b/test/com/sun/jndi/ldap/LdapDnsProviderTest.java                                                          |  230 
 b/test/com/sun/jndi/ldap/dnsprovider/TestDnsProvider.java                                                  |   20 
 b/test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.policy                                    |    1 
 b/test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java                                      |   12 
 b/test/java/security/testlibrary/CertificateBuilder.java                                                   |  539 +
 b/test/java/security/testlibrary/SimpleOCSPServer.java                                                     | 1581 ++++
 b/test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java                                                           |  585 +
 b/test/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java                                                     |    2 
 b/test/javax/net/ssl/ALPN/SSLSocketAlpnTest.java                                                           |    2 
 b/test/javax/net/ssl/FixingJavadocs/ComURLNulls.java                                                       |  121 
 b/test/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java                                                 |    2 
 b/test/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java                                                   |   98 
 b/test/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java                                                  |    2 
 b/test/javax/net/ssl/HttpsURLConnection/GetResponseCode.java                                               |    2 
 b/test/javax/net/ssl/SSLEngine/ArgCheck.java                                                               |    2 
 b/test/javax/net/ssl/SSLEngine/Arrays.java                                                                 |  320 
 b/test/javax/net/ssl/SSLEngine/Basics.java                                                                 |    2 
 b/test/javax/net/ssl/SSLEngine/CheckStatus.java                                                            |  714 +
 b/test/javax/net/ssl/SSLEngine/ConnectionTest.java                                                         |  685 +
 b/test/javax/net/ssl/SSLEngine/EngineCloseOnAlert.java                                                     |  374 
 b/test/javax/net/ssl/SSLEngine/ExtendedKeyEngine.java                                                      |  276 
 b/test/javax/net/ssl/SSLEngine/ExtendedKeySocket.java                                                      |    2 
 b/test/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java                                                |  110 
 b/test/javax/net/ssl/SSLEngine/IllegalRecordVersion.java                                                   |    2 
 b/test/javax/net/ssl/SSLEngine/LargeBufs.java                                                              |  312 
 b/test/javax/net/ssl/SSLEngine/LargePacket.java                                                            |    2 
 b/test/javax/net/ssl/SSLEngine/NoAuthClientAuth.java                                                       |  423 +
 b/test/javax/net/ssl/SSLEngine/SSLEngineService.java                                                       |    2 
 b/test/javax/net/ssl/SSLEngine/TestAllSuites.java                                                          |    2 
 b/test/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java                                               |    2 
 b/test/javax/net/ssl/SSLSession/CheckMyTrustedKeystore.java                                                |    2 
 b/test/javax/net/ssl/SSLSession/HttpsURLConnectionLocalCertificateChain.java                               |    2 
 b/test/javax/net/ssl/SSLSession/JSSERenegotiate.java                                                       |    2 
 b/test/javax/net/ssl/SSLSession/RenegotiateTLS13.java                                                      |  292 
 b/test/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java                                                    |  586 +
 b/test/javax/net/ssl/SSLSession/SSLCtxAccessToSessCtx.java                                                 |    2 
 b/test/javax/net/ssl/SSLSession/SessionCacheSizeTests.java                                                 |  497 +
 b/test/javax/net/ssl/SSLSession/SessionTimeOutTests.java                                                   |  510 +
 b/test/javax/net/ssl/SSLSession/TestEnabledProtocols.java                                                  |  283 
 b/test/javax/net/ssl/SSLSocket/InputStreamClosure.java                                                     |   81 
 b/test/javax/net/ssl/SSLSocket/OutputStreamClosure.java                                                    |   81 
 b/test/javax/net/ssl/SSLSocket/Tls13PacketSize.java                                                        |  100 
 b/test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java                                             |    2 
 b/test/javax/net/ssl/ServerName/SSLEngineExplorer.java                                                     |    4 
 b/test/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java                                           |    4 
 b/test/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java                                         |    4 
 b/test/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java                                              |    4 
 b/test/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java                                              |    4 
 b/test/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java                                                |    2 
 b/test/javax/net/ssl/ServerName/SSLSocketExplorer.java                                                     |    4 
 b/test/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java                                              |  387 +
 b/test/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java                                           |    4 
 b/test/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java                                         |    4 
 b/test/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java                                           |    4 
 b/test/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java                                           |    4 
 b/test/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java                                              |    2 
 b/test/javax/net/ssl/ServerName/SSLSocketSNISensitive.java                                                 |  578 +
 b/test/javax/net/ssl/Stapling/HttpsUrlConnClient.java                                                      |  853 ++
 b/test/javax/net/ssl/Stapling/SSLEngineWithStapling.java                                                   |  696 +
 b/test/javax/net/ssl/Stapling/SSLSocketWithStapling.java                                                   | 1299 +++
 b/test/javax/net/ssl/Stapling/StapleEnableProps.java                                                       |  843 ++
 b/test/javax/net/ssl/TLS/CipherTestUtils.java                                                              |  161 
 b/test/javax/net/ssl/TLS/JSSEClient.java                                                                   |   84 
 b/test/javax/net/ssl/TLS/JSSEServer.java                                                                   |   51 
 b/test/javax/net/ssl/TLS/TLSClientPropertyTest.java                                                        |   27 
 b/test/javax/net/ssl/TLS/TLSDataExchangeTest.java                                                          |   43 
 b/test/javax/net/ssl/TLS/TLSEnginesClosureTest.java                                                        |   42 
 b/test/javax/net/ssl/TLS/TLSHandshakeTest.java                                                             |   42 
 b/test/javax/net/ssl/TLS/TLSMFLNTest.java                                                                  |   44 
 b/test/javax/net/ssl/TLS/TLSNotEnabledRC4Test.java                                                         |   39 
 b/test/javax/net/ssl/TLS/TLSRehandshakeTest.java                                                           |   43 
 b/test/javax/net/ssl/TLS/TLSRehandshakeWithCipherChangeTest.java                                           |   43 
 b/test/javax/net/ssl/TLS/TLSRehandshakeWithDataExTest.java                                                 |   45 
 b/test/javax/net/ssl/TLS/TLSUnsupportedCiphersTest.java                                                    |   40 
 b/test/javax/net/ssl/TLS/TestJSSE.java                                                                     |  202 
 b/test/javax/net/ssl/TLS/TestJSSEClientDefaultProtocol.java                                                |   65 
 b/test/javax/net/ssl/TLS/TestJSSEClientProtocol.java                                                       |   76 
 b/test/javax/net/ssl/TLS/TestJSSENoCommonProtocols.java                                                    |   36 
 b/test/javax/net/ssl/TLS/TestJSSEServerProtocol.java                                                       |   61 
 b/test/javax/net/ssl/TLSCommon/BufferOverflowUnderflowTest.java                                            |  135 
 b/test/javax/net/ssl/TLSCommon/CipherSuite.java                                                            |  244 
 b/test/javax/net/ssl/TLSCommon/ConcurrentClientAccessTest.java                                             |  390 +
 b/test/javax/net/ssl/TLSCommon/DataExchangeTest.java                                                       |   55 
 b/test/javax/net/ssl/TLSCommon/EnginesClosureTest.java                                                     |   63 
 b/test/javax/net/ssl/TLSCommon/HandshakeTest.java                                                          |   52 
 b/test/javax/net/ssl/TLSCommon/KeyAlgorithm.java                                                           |   39 
 b/test/javax/net/ssl/TLSCommon/KeyExAlgorithm.java                                                         |   44 
 b/test/javax/net/ssl/TLSCommon/MFLNTest.java                                                               |   63 
 b/test/javax/net/ssl/TLSCommon/NotEnabledRC4Test.java                                                      |   54 
 b/test/javax/net/ssl/TLSCommon/Protocol.java                                                               |   54 
 b/test/javax/net/ssl/TLSCommon/RehandshakeTest.java                                                        |   58 
 b/test/javax/net/ssl/TLSCommon/RehandshakeWithCipherChangeTest.java                                        |   73 
 b/test/javax/net/ssl/TLSCommon/RehandshakeWithDataExTest.java                                              |   74 
 b/test/javax/net/ssl/TLSCommon/SSLEngineTestCase.java                                                      | 1212 +++
 b/test/javax/net/ssl/TLSCommon/TLSTest.java                                                                | 1245 +++
 b/test/javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java                                              |  344 
 b/test/javax/net/ssl/TLSCommon/UnsupportedCiphersTest.java                                                 |   55 
 b/test/javax/net/ssl/TLSCommon/jaas.conf                                                                   |   17 
 b/test/javax/net/ssl/TLSv1/TLSDataExchangeTest.java                                                        |   43 
 b/test/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java                                                      |   42 
 b/test/javax/net/ssl/TLSv1/TLSHandshakeTest.java                                                           |   42 
 b/test/javax/net/ssl/TLSv1/TLSMFLNTest.java                                                                |   44 
 b/test/javax/net/ssl/TLSv1/TLSNotEnabledRC4Test.java                                                       |   39 
 b/test/javax/net/ssl/TLSv1/TLSRehandshakeTest.java                                                         |   43 
 b/test/javax/net/ssl/TLSv1/TLSRehandshakeWithCipherChangeTest.java                                         |   43 
 b/test/javax/net/ssl/TLSv1/TLSRehandshakeWithDataExTest.java                                               |   45 
 b/test/javax/net/ssl/TLSv1/TLSUnsupportedCiphersTest.java                                                  |   40 
 b/test/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java                                               |    2 
 b/test/javax/net/ssl/TLSv11/ExportableBlockCipher.java                                                     |  337 
 b/test/javax/net/ssl/TLSv11/ExportableStreamCipher.java                                                    |  337 
 b/test/javax/net/ssl/TLSv11/GenericBlockCipher.java                                                        |    2 
 b/test/javax/net/ssl/TLSv11/GenericStreamCipher.java                                                       |    2 
 b/test/javax/net/ssl/TLSv11/TLSDataExchangeTest.java                                                       |   43 
 b/test/javax/net/ssl/TLSv11/TLSEnginesClosureTest.java                                                     |   42 
 b/test/javax/net/ssl/TLSv11/TLSHandshakeTest.java                                                          |   42 
 b/test/javax/net/ssl/TLSv11/TLSMFLNTest.java                                                               |   44 
 b/test/javax/net/ssl/TLSv11/TLSNotEnabledRC4Test.java                                                      |   39 
 b/test/javax/net/ssl/TLSv11/TLSRehandshakeTest.java                                                        |   43 
 b/test/javax/net/ssl/TLSv11/TLSRehandshakeWithCipherChangeTest.java                                        |   43 
 b/test/javax/net/ssl/TLSv11/TLSRehandshakeWithDataExTest.java                                              |   45 
 b/test/javax/net/ssl/TLSv11/TLSUnsupportedCiphersTest.java                                                 |   40 
 b/test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java                                                      |    8 
 b/test/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java                                                      |  261 
 b/test/javax/net/ssl/TLSv12/ProtocolFilter.java                                                            |    2 
 b/test/javax/net/ssl/TLSv12/ShortRSAKey512.java                                                            |  420 +
 b/test/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java                                                            |  446 +
 b/test/javax/net/ssl/TLSv12/SignatureAlgorithms.java                                                       |    5 
 b/test/javax/net/ssl/TLSv12/TLSEnginesClosureTest.java                                                     |   45 
 b/test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java                                                  |   19 
 b/test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java                                                 |   28 
 b/test/javax/net/ssl/compatibility/Cert.java                                                               |  413 +
 b/test/javax/net/ssl/compatibility/Client.java                                                             |  206 
 b/test/javax/net/ssl/compatibility/ClientHelloProcessing.java                                              |  781 ++
 b/test/javax/net/ssl/compatibility/Compatibility.java                                                      |  357 
 b/test/javax/net/ssl/compatibility/JdkInfo.java                                                            |   95 
 b/test/javax/net/ssl/compatibility/JdkRelease.java                                                         |   61 
 b/test/javax/net/ssl/compatibility/JdkUtils.java                                                           |  115 
 b/test/javax/net/ssl/compatibility/ProcessUtils.java                                                       |   59 
 b/test/javax/net/ssl/compatibility/README                                                                  |  130 
 b/test/javax/net/ssl/compatibility/Server.java                                                             |  174 
 b/test/javax/net/ssl/compatibility/Status.java                                                             |   30 
 b/test/javax/net/ssl/compatibility/TestCase.java                                                           |   64 
 b/test/javax/net/ssl/compatibility/UseCase.java                                                            |  205 
 b/test/javax/net/ssl/compatibility/Utils.java                                                              |  270 
 b/test/javax/net/ssl/compatibility/java.security                                                           |    2 
 b/test/javax/net/ssl/etc/README                                                                            |  116 
 b/test/javax/net/ssl/interop/ClientHelloBufferUnderflowException.java                                      |   84 
 b/test/javax/net/ssl/interop/ClientHelloChromeInterOp.java                                                 |   74 
 b/test/javax/net/ssl/interop/ClientHelloInterOp.java                                                       |  432 +
 b/test/javax/net/ssl/sanity/CacertsExplorer.java                                                           |   72 
 b/test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java                                            |  253 
 b/test/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java                                          |  264 
 b/test/javax/net/ssl/sanity/interop/CipherTest.java                                                        |  461 +
 b/test/javax/net/ssl/sanity/interop/ClientJSSEServerJSSE.java                                              |   59 
 b/test/javax/net/ssl/sanity/interop/JSSEClient.java                                                        |   99 
 b/test/javax/net/ssl/sanity/interop/JSSEServer.java                                                        |  100 
 b/test/javax/net/ssl/templates/SSLContextTemplate.java                                                     |  518 +
 b/test/javax/net/ssl/templates/SSLEngineTemplate.java                                                      |  428 +
 b/test/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java                                             |  532 +
 b/test/javax/net/ssl/templates/SSLSocketTemplate.java                                                      |  432 -
 b/test/jdk/internal/platform/docker/Dockerfile-BasicTest                                                   |    2 
 b/test/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java                        |  489 +
 b/test/sun/net/www/http/HttpClient/B8025710.java                                                           |    2 
 b/test/sun/net/www/protocol/https/ChunkedOutputStream.java                                                 |   10 
 b/test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java                                           |  250 
 b/test/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java                                      |  132 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java                                         |  192 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java                             |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java                                |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java                            |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java                                    |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java                              |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java                                        |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java                               |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java                           |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java                            |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java                                     |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/Identities.java                                       |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java                                      |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java                                    |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java                            |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java                                      |  347 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java                                         |    2 
 b/test/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java                                       |    2 
 b/test/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java                                          |  391 +
 b/test/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java                                         |  360 
 b/test/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java                                        |    2 
 b/test/sun/security/lib/cacerts/VerifyCACerts.java                                                         |   12 
 b/test/sun/security/pkcs11/Cipher/ReinitCipher.java                                                        |   17 
 b/test/sun/security/pkcs11/Cipher/Test4512704.java                                                         |   76 
 b/test/sun/security/pkcs11/Cipher/TestCICOWithGCM.java                                                     |  109 
 b/test/sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java                                               |  122 
 b/test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java                                                |  197 
 b/test/sun/security/pkcs11/Cipher/TestKATForGCM.java                                                       |  322 
 b/test/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java                                               |   26 
 b/test/sun/security/pkcs11/Cipher/TestRSACipher.java                                                       |   24 
 b/test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java                                                   |   22 
 b/test/sun/security/pkcs11/Cipher/TestRawRSACipher.java                                                    |   19 
 b/test/sun/security/pkcs11/Cipher/TestSymmCiphers.java                                                     |   24 
 b/test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java                                                |   28 
 b/test/sun/security/pkcs11/KeyAgreement/TestDH.java                                                        |   20 
 b/test/sun/security/pkcs11/KeyAgreement/TestInterop.java                                                   |   21 
 b/test/sun/security/pkcs11/KeyAgreement/TestShort.java                                                     |   21 
 b/test/sun/security/pkcs11/KeyGenerator/DESParity.java                                                     |   22 
 b/test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java                                              |   18 
 b/test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java                                                |   15 
 b/test/sun/security/pkcs11/Mac/MacKAT.java                                                                 |    7 
 b/test/sun/security/pkcs11/Mac/MacSameTest.java                                                            |    7 
 b/test/sun/security/pkcs11/Mac/ReinitMac.java                                                              |   17 
 b/test/sun/security/pkcs11/MessageDigest/ByteBuffers.java                                                  |   61 
 b/test/sun/security/pkcs11/MessageDigest/DigestKAT.java                                                    |   21 
 b/test/sun/security/pkcs11/MessageDigest/ReinitDigest.java                                                 |   14 
 b/test/sun/security/pkcs11/MessageDigest/TestCloning.java                                                  |   14 
 b/test/sun/security/pkcs11/PKCS11Test.java                                                                 |  150 
 b/test/sun/security/pkcs11/Secmod/AddPrivateKey.java                                                       |   32 
 b/test/sun/security/pkcs11/Secmod/AddTrustedCert.java                                                      |   28 
 b/test/sun/security/pkcs11/Secmod/Crypto.java                                                              |   15 
 b/test/sun/security/pkcs11/Secmod/GetPrivateKey.java                                                       |   25 
 b/test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java                                                    |   39 
 b/test/sun/security/pkcs11/Secmod/LoadKeystore.java                                                        |   10 
 b/test/sun/security/pkcs11/Secmod/README-SQLITE                                                            |    8 
 b/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java                                                     |  127 
 b/test/sun/security/pkcs11/Secmod/TrustAnchors.java                                                        |   25 
 b/test/sun/security/pkcs11/Secmod/nss-sqlite.cfg                                                           |   13 
 b/test/sun/security/pkcs11/Secmod/policy                                                                   |    6 
 b/test/sun/security/pkcs11/SecmodTest.java                                                                 |   23 
 b/test/sun/security/pkcs11/SecureRandom/Basic.java                                                         |   16 
 b/test/sun/security/pkcs11/Signature/ByteBuffers.java                                                      |   17 
 b/test/sun/security/pkcs11/Signature/InitAgainPSS.java                                                     |   87 
 b/test/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java                                           |  132 
 b/test/sun/security/pkcs11/Signature/SigInteropPSS.java                                                    |  121 
 b/test/sun/security/pkcs11/Signature/SignatureTestPSS.java                                                 |  147 
 b/test/sun/security/pkcs11/Signature/TestDSA.java                                                          |   25 
 b/test/sun/security/pkcs11/Signature/TestDSA2.java                                                         |   93 
 b/test/sun/security/pkcs11/Signature/TestDSAKeyLength.java                                                 |   18 
 b/test/sun/security/pkcs11/Signature/TestRSAKeyLength.java                                                 |   18 
 b/test/sun/security/pkcs11/ec/ReadCertificates.java                                                        |   54 
 b/test/sun/security/pkcs11/ec/ReadPKCS12.java                                                              |   83 
 b/test/sun/security/pkcs11/ec/TestCurves.java                                                              |   32 
 b/test/sun/security/pkcs11/ec/TestECDH.java                                                                |   30 
 b/test/sun/security/pkcs11/ec/TestECDH2.java                                                               |   40 
 b/test/sun/security/pkcs11/ec/TestECDSA.java                                                               |   32 
 b/test/sun/security/pkcs11/ec/TestECDSA2.java                                                              |   37 
 b/test/sun/security/pkcs11/ec/TestECGenSpec.java                                                           |   21 
 b/test/sun/security/pkcs11/ec/TestKeyFactory.java                                                          |   26 
 b/test/sun/security/pkcs11/ec/policy                                                                       |    7 
 b/test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java                                                  |    2 
 b/test/sun/security/pkcs11/fips/TrustManagerTest.java                                                      |   37 
 b/test/sun/security/pkcs11/fips/TrustManagerTest.policy                                                    |    3 
 b/test/sun/security/pkcs11/policy                                                                          |    3 
 b/test/sun/security/pkcs11/rsa/KeyWrap.java                                                                |   30 
 b/test/sun/security/pkcs11/rsa/TestCACerts.java                                                            |   33 
 b/test/sun/security/pkcs11/rsa/TestCACerts.policy                                                          |    7 
 b/test/sun/security/pkcs11/rsa/TestKeyFactory.java                                                         |   19 
 b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java                                                   |   23 
 b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.policy                                                 |    4 
 b/test/sun/security/pkcs11/rsa/TestSignatures.java                                                         |   41 
 b/test/sun/security/pkcs11/rsa/rsakeys.ks.policy                                                           |    4 
 b/test/sun/security/pkcs11/sslecc/CipherTest.java                                                          |  196 
 b/test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java                                                |   31 
 b/test/sun/security/pkcs11/sslecc/JSSEClient.java                                                          |   41 
 b/test/sun/security/pkcs11/sslecc/JSSEServer.java                                                          |   56 
 b/test/sun/security/pkcs11/sslecc/policy                                                                   |    9 
 b/test/sun/security/pkcs11/tls/TestKeyMaterial.java                                                        |  216 
 b/test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java                                                   |   22 
 b/test/sun/security/pkcs11/tls/TestMasterSecret.java                                                       |  165 
 b/test/sun/security/pkcs11/tls/TestMasterSecret.policy                                                     |    8 
 b/test/sun/security/pkcs11/tls/TestPRF.java                                                                |  164 
 b/test/sun/security/pkcs11/tls/TestPremaster.java                                                          |   11 
 b/test/sun/security/pkcs11/tls/policy                                                                      |    5 
 b/test/sun/security/provider/X509Factory/BadPem.java                                                       |    2 
 b/test/sun/security/provider/X509Factory/BigCRL.java                                                       |    2 
 b/test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java                              |  366 
 b/test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java                                    |  419 +
 b/test/sun/security/ssl/AppInputStream/ReadBlocksClose.java                                                |  327 
 b/test/sun/security/ssl/AppInputStream/ReadHandshake.java                                                  |  317 
 b/test/sun/security/ssl/AppInputStream/ReadZeroBytes.java                                                  |    2 
 b/test/sun/security/ssl/AppInputStream/RemoveMarkReset.java                                                |    2 
 b/test/sun/security/ssl/AppOutputStream/NoExceptionOnClose.java                                            |  284 
 b/test/sun/security/ssl/CertPathRestrictions/JSSEServer.java                                               |    4 
 b/test/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java                                          |   21 
 b/test/sun/security/ssl/CipherSuite/SSL_NULL.java                                                          |   96 
 b/test/sun/security/ssl/ClientHandshaker/CipherSuiteOrder.java                                             |    2 
 b/test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java                                              |  817 ++
 b/test/sun/security/ssl/DHKeyExchange/DHEKeySizing.java                                                    |  503 +
 b/test/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java                                            |    8 
 b/test/sun/security/ssl/DHKeyExchange/UseStrongDHSizes.java                                                |  111 
 b/test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.java                                           |    2 
 b/test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.sh                                             |   81 
 b/test/sun/security/ssl/GenSSLConfigs/main.java                                                            |  275 
 b/test/sun/security/ssl/HandshakeOutStream/NullCerts.java                                                  |    3 
 b/test/sun/security/ssl/InputRecord/ClientHelloRead.java                                                   |    2 
 b/test/sun/security/ssl/InputRecord/SSLSocketTimeoutNulls.java                                             |  291 
 b/test/sun/security/ssl/ProtocolVersion/HttpsProtocols.java                                                |    2 
 b/test/sun/security/ssl/SSLContextImpl/BadKSProvider.java                                                  |    2 
 b/test/sun/security/ssl/SSLContextImpl/BadTSProvider.java                                                  |    2 
 b/test/sun/security/ssl/SSLContextImpl/CustomizedCipherSuites.java                                         |    2 
 b/test/sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java                                     |  272 
 b/test/sun/security/ssl/SSLContextImpl/CustomizedServerDefaultProtocols.java                               |  289 
 b/test/sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java                                        |  271 
 b/test/sun/security/ssl/SSLContextImpl/GoodProvider.java                                                   |    2 
 b/test/sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java                                               |  331 
 b/test/sun/security/ssl/SSLContextImpl/NoOldVersionContext.java                                            |  273 
 b/test/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java                                               |  327 
 b/test/sun/security/ssl/SSLEngineImpl/CloseEngineException.java                                            |  294 
 b/test/sun/security/ssl/SSLEngineImpl/CloseStart.java                                                      |  124 
 b/test/sun/security/ssl/SSLEngineImpl/DelegatedTaskWrongException.java                                     |    2 
 b/test/sun/security/ssl/SSLEngineImpl/EmptyExtensionData.java                                              |    2 
 b/test/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java                                      |  321 
 b/test/sun/security/ssl/SSLEngineImpl/RehandshakeFinished.java                                             |  523 +
 b/test/sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java                                   |  616 +
 b/test/sun/security/ssl/SSLEngineImpl/SSLEngineDeadlock.java                                               |  412 +
 b/test/sun/security/ssl/SSLEngineImpl/SSLEngineFailedALPN.java                                             |  449 +
 b/test/sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java                                               |  482 +
 b/test/sun/security/ssl/SSLEngineImpl/TLS13BeginHandshake.java                                             |  193 
 b/test/sun/security/ssl/SSLSessionImpl/HashCodeMissing.java                                                |    2 
 b/test/sun/security/ssl/SSLSessionImpl/ResumeChecksClient.java                                             |  346 
 b/test/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java                                             |  307 
 b/test/sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java                                             |  139 
 b/test/sun/security/ssl/SSLSocketImpl/CheckMethods.java                                                    |  142 
 b/test/sun/security/ssl/SSLSocketImpl/ClientModeClientAuth.java                                            |    2 
 b/test/sun/security/ssl/SSLSocketImpl/ClientTimeout.java                                                   |  371 
 b/test/sun/security/ssl/SSLSocketImpl/CloseSocketException.java                                            |    2 
 b/test/sun/security/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java                              |  325 
 b/test/sun/security/ssl/SSLSocketImpl/LargePacketAfterHandshakeTest.java                                   |  183 
 b/test/sun/security/ssl/SSLSocketImpl/NewSocketMethods.java                                                |    2 
 b/test/sun/security/ssl/SSLSocketImpl/NoImpactServerRenego.java                                            |  326 
 b/test/sun/security/ssl/SSLSocketImpl/NonAutoClose.java                                                    |  380 +
 b/test/sun/security/ssl/SSLSocketImpl/NotifyHandshakeTest.java                                             |    2 
 b/test/sun/security/ssl/SSLSocketImpl/RejectClientRenego.java                                              |  340 
 b/test/sun/security/ssl/SSLSocketImpl/ReuseAddr.java                                                       |    2 
 b/test/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java                                               |    2 
 b/test/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java                                          |  162 
 b/test/sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java                                              |    2 
 b/test/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java                              |  315 
 b/test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java                                               |  302 
 b/test/sun/security/ssl/SSLSocketImpl/ServerRenegoWithTwoVersions.java                                     |  329 
 b/test/sun/security/ssl/SSLSocketImpl/ServerTimeout.java                                                   |    2 
 b/test/sun/security/ssl/SSLSocketImpl/SetClientMode.java                                                   |  189 
 b/test/sun/security/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java                                |    2 
 b/test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java                                 |   87 
 b/test/sun/security/ssl/ServerHandshaker/GetPeerHost.java                                                  |    2 
 b/test/sun/security/ssl/ServerHandshaker/GetPeerHostClient.java                                            |    1 
 b/test/sun/security/ssl/ServerHandshaker/GetPeerHostServer.java                                            |    2 
 b/test/sun/security/ssl/ServerHandshaker/HelloExtensionsTest.java                                          |    2 
 b/test/sun/security/ssl/SignatureScheme/Tls13NamedGroups.java                                              |  188 
 b/test/sun/security/ssl/SocketCreation/SocketCreation.java                                                 |  511 +
 b/test/sun/security/ssl/Stapling/StatusResponseManager.sh                                                  |  100 
 b/test/sun/security/ssl/Stapling/java.base/sun/security/ssl/StatusResponseManagerTests.java                |  492 +
 b/test/sun/security/ssl/X509KeyManager/PreferredKey.java                                                   |    2 
 b/test/sun/security/ssl/X509KeyManager/SelectOneKeyOutOfMany.java                                          |    2 
 b/test/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java                                         |  565 +
 b/test/sun/security/ssl/X509TrustManagerImpl/CertRequestOverflow.java                                      |  417 +
 b/test/sun/security/ssl/X509TrustManagerImpl/CheckNullEntity.java                                          |    2 
 b/test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java                                             |  364 
 b/test/sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java                                           |  413 +
 b/test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java                                        |  269 
 b/test/sun/security/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java                                    |    2 
 b/test/sun/security/ssl/internal/TestRun.sh                                                                |   93 
 b/test/sun/security/ssl/internal/java.base/sun/security/ssl/TestHkdf.java                                  |  260 
 b/test/sun/security/ssl/spi/ProviderInit.java                                                              |    2 
 b/test/sun/security/tools/keytool/PrintSSL.java                                                            |    2 
 670 files changed, 101443 insertions(+), 55250 deletions(-)

diffstat for hotspot
 b/.hgtags                                                        |    1 
 b/THIRD_PARTY_README                                             |   41 +++++++++
 b/make/aix/makefiles/buildtree.make                              |    2 
 b/make/aix/makefiles/vm.make                                     |    2 
 b/make/bsd/makefiles/buildtree.make                              |    2 
 b/make/bsd/makefiles/vm.make                                     |    2 
 b/make/linux/makefiles/buildtree.make                            |    2 
 b/make/linux/makefiles/vm.make                                   |    2 
 b/make/solaris/makefiles/buildtree.make                          |    2 
 b/make/solaris/makefiles/vm.make                                 |    2 
 b/src/share/vm/compiler/disassembler.cpp                         |   28 +++---
 b/src/share/vm/opto/output.cpp                                   |    2 
 b/src/share/vm/prims/jniCheck.cpp                                |    9 --
 b/src/share/vm/runtime/globals.hpp                               |    2 
 b/src/share/vm/utilities/globalDefinitions.hpp                   |    1 
 b/src/share/vm/utilities/stack.inline.hpp                        |    7 -
 b/test/runtime/CommandLine/TraceExceptionsTest.java              |    5 -
 b/test/runtime/containers/docker/CheckOperatingSystemMXBean.java |   43 ++++++++++
 b/test/runtime/containers/docker/Dockerfile-BasicTest            |    2 
 b/test/runtime/containers/docker/TestCPUAwareness.java           |   29 ++++++
 b/test/runtime/containers/docker/TestMemoryAwareness.java        |   34 +++++++
 21 files changed, 181 insertions(+), 39 deletions(-)

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le, aarch32 (Zero) & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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  Mon Sep  7 07:58:55 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 7 Sep 2020 09:58:55 +0200
Subject: [RFR] [8u] 8u272-b06 Upstream Sync
In-Reply-To: <20200907072946.GF1707023@stopbrexit>
References: <20200907072946.GF1707023@stopbrexit>
Message-ID: <360e6306-c213-ce94-7241-f841b81ffdcc@redhat.com>

On 9/7/20 9:29 AM, Andrew Hughes wrote:
> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/
> 
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/jaxws/merge.changeset

Look trivially good.

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

Looks like TLS 1.3 integration. Seems fine.

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

Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/langtools/merge.changeset

Looks good.

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

Look good.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Sep  7 08:17:52 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 7 Sep 2020 10:17:52 +0200
Subject: [15u] RFR (S) 8252648: Shenandoah: name gang tasks consistently
Message-ID: <4596e8a6-cb7e-fec0-54fe-6663ad2196ec@redhat.com>

Original fix:
   https://bugs.openjdk.java.net/browse/JDK-8252648
   https://hg.openjdk.java.net/jdk/jdk/rev/1a839c572dfd

There is a little conflict around ShenandoahConcurrentWeakRootsEvacUpdateTask definition, resolved 
by hand.

15u webrev:
   https://cr.openjdk.java.net/~shade/8252648/webrev.15u.01/

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From stefank at openjdk.java.net  Mon Sep  7 08:28:22 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 7 Sep 2020 08:28:22 GMT
Subject: RFR: 8250961: Move Universe::update_heap_info_at_gc to
 CollectedHeap
In-Reply-To: <M7mmA8k0wOMopPaGMpN_C473ruGq61Wg4jUw-uxrLL0=.11a00df6-9e05-4728-b8b0-5f8d71e57238@github.com>
References: <M7mmA8k0wOMopPaGMpN_C473ruGq61Wg4jUw-uxrLL0=.11a00df6-9e05-4728-b8b0-5f8d71e57238@github.com>
Message-ID: <nA4U9dDA3V9Y2PflmtmmxUyFe8dIPHjPnkZmP27oCBY=.897f35dc-f9ae-419f-af29-7b55835a5a2a@github.com>

On Sun, 6 Sep 2020 07:00:36 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

> This is a small refactoring that moves `update_heap_info_at_gc()` and related members to `CollectedHeap`. There should
> be no behavioral change.
> jdk/hotspot tier1 passed
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8250961

src/hotspot/share/gc/shared/collectedHeap.hpp line 443:

> 441:   size_t _heap_capacity_at_last_gc;
> 442:   size_t _heap_used_at_last_gc;
> 443:

These should be initialized in the constructor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/27

From shade at redhat.com  Mon Sep  7 11:29:22 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 7 Sep 2020 13:29:22 +0200
Subject: [11u] RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize
 option
Message-ID: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com>

Original RFE:
   https://bugs.openjdk.java.net/browse/JDK-8252660
   https://hg.openjdk.java.net/jdk/jdk/rev/6ab9279c0e99

The patch does not apply cleanly to 11u, because there are conflicts in APIs.

I had to resolve these:
   *) There is no Atomic::store(&size_t, size_t), replaced with OrderAccess::release_store_fence, as 
in other places in 11u.
   *) There is no global SoftMaxHeapSize, replaced it with ShenandoahSoftMaxHeapSize and added 
relevant verifications to make new Shenandoah tests pass.

11u webrev:
   https://cr.openjdk.java.net/~shade/8252660/webrev.11u.01/

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

-- 
Thanks,
-Aleksey


From fweimer at redhat.com  Mon Sep  7 12:07:44 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 07 Sep 2020 14:07:44 +0200
Subject: RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize
 option
In-Reply-To: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com> (Aleksey
 Shipilev's message of "Tue, 1 Sep 2020 20:55:14 +0200")
References: <3f24ee51-bb7f-6442-271c-7c3d875d7ba3@redhat.com>
Message-ID: <87v9gp4wof.fsf@oldenburg2.str.redhat.com>

* Aleksey Shipilev:

> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8252660
>
> Since JDK 13, there is a SoftMaxHeapSize option that basically
> instructs GC heuristics to target that particular heap size, while
> leaving the headroom for allocation spikes and other contingencies. It
> makes sense to support this in Shenandoah.

I think G1 supports SoftMaxHeapSize as well, but it does not run
back-to-back collections once the live set exceeds the configured size.
Obviously, it's likely that those back-to-back collections only burn CPU
cycles without bringing the heap size down below SoftMaxHeapSize.

ZGC seems to be have more like Shenandoah with this patch, I think.
There's no G1-style backoff, either.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


From shade at openjdk.java.net  Mon Sep  7 12:10:31 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Sep 2020 12:10:31 GMT
Subject: RFR: 8252695: Shenandoah: clean up Graal enabled/disabled filter in
 tests
Message-ID: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>

Drop `!vm.graal.enabled` since it is not required after JDK-8249000.

-------------

Commit messages:
 - JDK-8252695

Changes: https://git.openjdk.java.net/jdk/pull/51/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=51&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252695
  Stats: 51 lines in 13 files changed: 0 ins; 0 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/51/head:pull/51

PR: https://git.openjdk.java.net/jdk/pull/51

From shade at openjdk.java.net  Mon Sep  7 13:10:49 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Sep 2020 13:10:49 GMT
Subject: RFR: 8240751: Shenandoah: fold ShenandoahTracer definition
Message-ID: <ZAiMCKzw5hzLzZk-fAvD8K6P3kOZ2-ZrwZ9jVgesaQI=.3fa0841d-612f-4198-abf6-c2ca6b513535@github.com>

Currently, we have `shenandoahTracer.hpp` with a sole definition:
class ShenandoahTracer : public GCTracer {
public:
  ShenandoahTracer() : GCTracer(Shenandoah) {}
};

This can be folded near the only use at `shenandoahCollectorPolicy.hpp`.

-------------

Commit messages:
 - JDK-8240751: Shenandoah: fold ShenandoahTracer definition

Changes: https://git.openjdk.java.net/jdk/pull/55/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=55&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8240751
  Stats: 41 lines in 2 files changed: 6 ins; 35 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/55.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/55/head:pull/55

PR: https://git.openjdk.java.net/jdk/pull/55

From shade at openjdk.java.net  Mon Sep  7 13:49:03 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Sep 2020 13:49:03 GMT
Subject: RFR: 8240751: Shenandoah: fold ShenandoahTracer definition [v2]
In-Reply-To: <ZAiMCKzw5hzLzZk-fAvD8K6P3kOZ2-ZrwZ9jVgesaQI=.3fa0841d-612f-4198-abf6-c2ca6b513535@github.com>
References: <ZAiMCKzw5hzLzZk-fAvD8K6P3kOZ2-ZrwZ9jVgesaQI=.3fa0841d-612f-4198-abf6-c2ca6b513535@github.com>
Message-ID: <he1MA4ldvIvUr0VMk2XI26PCvX5loR7g9nVThi8HNLM=.93237f05-2c1a-46c1-884e-7fb0ae0676e4@github.com>

> Currently, we have `shenandoahTracer.hpp` with a sole definition:
> class ShenandoahTracer : public GCTracer {
> public:
>   ShenandoahTracer() : GCTracer(Shenandoah) {}
> };
> 
> This can be folded near the only use at `shenandoahCollectorPolicy.hpp`.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Leftover include of deleted file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/55/files
  - new: https://git.openjdk.java.net/jdk/pull/55/files/f2a8df43..51b7572f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=55&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=55&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/55.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/55/head:pull/55

PR: https://git.openjdk.java.net/jdk/pull/55

From kornelpal at gmail.com  Mon Sep  7 17:08:42 2020
From: kornelpal at gmail.com (Kornel Pal)
Date: Mon, 7 Sep 2020 19:08:42 +0200
Subject: [8] RFR: Shenandoah: JNI weak roots are always cleared before
 Full GC mark
In-Reply-To: <377ad052-c58c-9348-493c-2d20525b4c8a@redhat.com>
References: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
 <6a7ced31-4d50-8611-c46c-ff8d8a766503@gmail.com>
 <377ad052-c58c-9348-493c-2d20525b4c8a@redhat.com>
Message-ID: <2259ba49-430d-d2c3-c447-1ce347b4aeca@gmail.com>

Hi Zhengyu,

Thank you for getting back to me and preparing the change this quickly.

I'm looking forward to see the change in the nightly builds.

Thank you,
Kornel

On 2020-08-28. 14:36, Zhengyu Gu wrote:
> Hi Kornel,
> 
> Yes, I will RFR to backout this workaround.
> 
> Thanks,
> 
> -Zhengyu
> 
> On 8/28/20 12:52 AM, Kornel Pal wrote:
>> Hi Aleksey,
>>
>> Thank you very much for all the dedicated work on Shenandoah GC, it 
>> really is useful.
>>
>> I wonder whether this workaround could safely be removed, now that 
>> JDK-8248041 was backported to 8u.
>>
>> Thank you,
>> Kornel
>>
>> On 2020-06-22 19:39, 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 dholmes at openjdk.java.net  Mon Sep  7 21:47:48 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Sep 2020 21:47:48 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function
Message-ID: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>

This is a rather large but generally simple cleanup.

We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
also added to allow use in cases where we start with "const Thread *".

Summary of changes:
- changed raw casts to use as_Java_thread()
- removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
- Removed checks that are checking the type system e.g.
void foo(JavaThread* t) {
  assert(t->is_Java_thread(), "must be")
the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
assertion is at the head of any such call chain.

- Removed asserts that are already guaranteed in the caller.
- Use JavaThread::current() where appropriate.
- Use pre-existing "thread" variable where available rather than casting THREAD

Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
been missed.

Testing: tiers 1-3

Thanks,
David

-------------

Commit messages:
 - Initial changes for 8252406

Changes: https://git.openjdk.java.net/jdk/pull/37/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252406
  Stats: 463 lines in 112 files changed: 15 ins; 124 del; 324 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From shade at openjdk.java.net  Mon Sep  7 21:47:48 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Sep 2020 21:47:48 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <NfcISc8m9KnR7LuRYw9WY6JZxQT9lQdbaPgnWbeg43E=.f7982ce9-1b9d-4f8d-927a-6c9bb6666fe3@github.com>

On Mon, 7 Sep 2020 05:56:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

Drive-by comment: Shenandoah changes look good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From dholmes at openjdk.java.net  Mon Sep  7 21:47:48 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Sep 2020 21:47:48 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function
In-Reply-To: <NfcISc8m9KnR7LuRYw9WY6JZxQT9lQdbaPgnWbeg43E=.f7982ce9-1b9d-4f8d-927a-6c9bb6666fe3@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <NfcISc8m9KnR7LuRYw9WY6JZxQT9lQdbaPgnWbeg43E=.f7982ce9-1b9d-4f8d-927a-6c9bb6666fe3@github.com>
Message-ID: <RHD0aX3K518f7UBGnuNLJ7bV7-R9ng5VvP4_UHUmAIs=.e603f861-6c7c-4cac-910f-3b81d27790a6@github.com>

On Mon, 7 Sep 2020 13:37:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is a rather large but generally simple cleanup.
>> 
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>   assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>> 
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> Drive-by comment: Shenandoah changes look good.

Thanks @shipilev ! Sending this out for RFR now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From kim.barrett at oracle.com  Mon Sep  7 23:23:51 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 7 Sep 2020 19:23:51 -0400
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <7A59E0A1-6D4B-4593-8E86-919B27EEBCAA@oracle.com>

> On Sep 7, 2020, at 5:47 PM, David Holmes <dholmes at openjdk.java.net> wrote:
> 
> [?]
> Commit messages:
> - Initial changes for 8252406
> 
> Changes: https://git.openjdk.java.net/jdk/pull/37/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8252406
>  Stats: 463 lines in 112 files changed: 15 ins; 124 del; 324 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37
> 
> PR: https://git.openjdk.java.net/jdk/pull/37

------------------------------------------------------------------------------
src/hotspot/share/runtime/thread.hpp
 506   JavaThread* as_Java_thread() {
 507     assert(is_Java_thread(), "incorrect cast to JavaThread");
 508     return (JavaThread*)this;
 509   }

This should be using a static_cast.  However, making that change will
uncover a problem.

This definition cannot correctly be located here. It must follow the
definition of the JavaThread class. At this point (in the body of the
Thread class definition), JavaThread is incomplete, so the C-style
cast is a reinterpret_cast. It's only by implementation accident (and
that we're not using multiple or virtual inheritance anywhere in the
vicinity), that a reinterpret_cast happens to work.

(The definition can remain in this file if that's more
convenient #include-wise than putting it in thread.inline.hpp, though
the latter would be the more usual placement.)

(One of the very real dangers with C-style casts is that you might not
be doing the cast you think you are doing.)

------------------------------------------------------------------------------
src/hotspot/share/runtime/thread.hpp
 510   JavaThread * as_const_Java_thread() const {
 511     assert(is_Java_thread(), "incorrect cast to JavaThread");
 512     return (JavaThread*)this;
 513   }

This should be

const JavaThread* as_Java_Thread() const {
  assert(is_Java_thread(), "incorrect cast to JavaThread");
  return static_cast<const JavaThread*>(this);
}

And of course, moved after the definition of JavaThread, per the above
discussion of the non-const function.

------------------------------------------------------------------------------

I reviewed all the (non-Shenandoah) gc changes, and they look good.


From david.holmes at oracle.com  Tue Sep  8 01:31:59 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Sep 2020 11:31:59 +1000
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function
In-Reply-To: <7A59E0A1-6D4B-4593-8E86-919B27EEBCAA@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <7A59E0A1-6D4B-4593-8E86-919B27EEBCAA@oracle.com>
Message-ID: <73622215-c297-f47e-069b-1746fae3121f@oracle.com>

Hi Kim,

Thanks for taking a look.

On 8/09/2020 9:23 am, Kim Barrett wrote:
>> On Sep 7, 2020, at 5:47 PM, David Holmes <dholmes at openjdk.java.net> wrote:
>>
>> [?]
>> Commit messages:
>> - Initial changes for 8252406
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/37/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8252406
>>   Stats: 463 lines in 112 files changed: 15 ins; 124 del; 324 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/37.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37
>>
>> PR: https://git.openjdk.java.net/jdk/pull/37
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/thread.hpp
>   506   JavaThread* as_Java_thread() {
>   507     assert(is_Java_thread(), "incorrect cast to JavaThread");
>   508     return (JavaThread*)this;
>   509   }
> 
> This should be using a static_cast.  However, making that change will
> uncover a problem.
> 
> This definition cannot correctly be located here. It must follow the
> definition of the JavaThread class.

I did try to do the right thing with static_cast and of course 
discovered that I couldn't use it at that location. As I was replacing 
C-style casts, and as other C-style casts continue to be used in similar 
methods, I just kept with the C-styler cast.

> At this point (in the body of the
> Thread class definition), JavaThread is incomplete, so the C-style
> cast is a reinterpret_cast. It's only by implementation accident (and
> that we're not using multiple or virtual inheritance anywhere in the
> vicinity), that a reinterpret_cast happens to work.
> 
> (The definition can remain in this file if that's more
> convenient #include-wise than putting it in thread.inline.hpp, though
> the latter would be the more usual placement.)

Okay I will look at what is involved in putting it in the .inline.hpp 
file; if that causes too many problems then I'll just shift it to an 
inline definition later in the hpp file.

> (One of the very real dangers with C-style casts is that you might not
> be doing the cast you think you are doing.)
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/thread.hpp
>   510   JavaThread * as_const_Java_thread() const {
>   511     assert(is_Java_thread(), "incorrect cast to JavaThread");
>   512     return (JavaThread*)this;
>   513   }
> 
> This should be
> 
> const JavaThread* as_Java_Thread() const {
>    assert(is_Java_thread(), "incorrect cast to JavaThread");
>    return static_cast<const JavaThread*>(this);
> }
> 
> And of course, moved after the definition of JavaThread, per the above
> discussion of the non-const function.

Will fix.

> ------------------------------------------------------------------------------
> 
> I reviewed all the (non-Shenandoah) gc changes, and they look good.

Thanks for the review and coding tips!

Cheers,
David


From lzang at openjdk.java.net  Tue Sep  8 03:24:22 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 8 Sep 2020 03:24:22 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap
Message-ID: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>

- enable parallel heap inspecton for ShenandoahHeap
  - preliminary evaluation:
    Time of jmap histo on (8GB heap with 4GB objects)
    * before: 5.186s
    * after : 1.698s

-------------

Commit messages:
 - 8252104: parallel heap inspection for ShenandoahHeap

Changes: https://git.openjdk.java.net/jdk/pull/67/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252104
  Stats: 179 lines in 2 files changed: 179 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/67/head:pull/67

PR: https://git.openjdk.java.net/jdk/pull/67

From dholmes at openjdk.java.net  Tue Sep  8 04:09:14 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Sep 2020 04:09:14 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v2]
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <GM65-STpiScugaJ1KHvz7TqN28ooZIKjEZAYr2xYPhY=.e26bf9f9-1c40-43f9-b08f-5b0f94c4818e@github.com>

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Used static_cast instead of raw C-style cast
  Moved inline functions to thread.inline.hpp
  Updated #includes to deal with the move to thread.inline.hpp
  Updated copyright year where needed.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/37/files
  - new: https://git.openjdk.java.net/jdk/pull/37/files/b18faad5..da70f804

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00-01

  Stats: 102 lines in 33 files changed: 39 ins; 28 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From dholmes at openjdk.java.net  Tue Sep  8 04:38:43 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Sep 2020 04:38:43 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v3]
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <IFJ1QBz9-OPXicX_rWNjGurKF4kp6eRDiVlH2rddMmo=.57579ae3-035e-4302-a6fd-aab1130d9648@github.com>

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  More missing includes of thread.inline.hpp
  
  The fanout for this change is now quite large.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/37/files
  - new: https://git.openjdk.java.net/jdk/pull/37/files/da70f804..68995170

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01-02

  Stats: 8 lines in 7 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From kim.barrett at oracle.com  Tue Sep  8 06:34:17 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 8 Sep 2020 02:34:17 -0400
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v2]
In-Reply-To: <GM65-STpiScugaJ1KHvz7TqN28ooZIKjEZAYr2xYPhY=.e26bf9f9-1c40-43f9-b08f-5b0f94c4818e@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <GM65-STpiScugaJ1KHvz7TqN28ooZIKjEZAYr2xYPhY=.e26bf9f9-1c40-43f9-b08f-5b0f94c4818e@github.com>
Message-ID: <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com>

> On Sep 8, 2020, at 12:09 AM, David Holmes <dholmes at openjdk.java.net> wrote:
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>  Used static_cast instead of raw C-style cast
>  Moved inline functions to thread.inline.hpp
>  Updated #includes to deal with the move to thread.inline.hpp
>  Updated copyright year where needed.
> 
> -------------
> 
> Changes:
>  - all: https://git.openjdk.java.net/jdk/pull/37/files
>  - new: https://git.openjdk.java.net/jdk/pull/37/files/b18faad5..da70f804
> 
> Webrevs:
> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01
> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00-01
> 
>  Stats: 102 lines in 33 files changed: 39 ins; 28 del; 35 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37
> 
> PR: https://git.openjdk.java.net/jdk/pull/37

------------------------------------------------------------------------------
src/hotspot/share/runtime/thread.hpp
 507   const JavaThread* as_const_Java_thread() const;

This missed part of what I'd suggested. I don't think the "const" part
of the name is needed or helpful.  Just overload as_Java_thread on the
const-ness of the thread it's being applied to.

There are some situations where there is such an overload pair and it
is useful to additionally have an explicit const function, but I don't
think this is one of those.

------------------------------------------------------------------------------

The fannout from putting the conversion functions in thread.inline.hpp seems
pretty high in the number of files that get touched. Especially since it
leads to JavaThread::current() and JavaThread::as_CompilerThread() being
moved. I would have been at least fine with, and probably would prefer,
having the definitions of as_JavaThread near the old definitions of those
functions in thread.hpp.

------------------------------------------------------------------------------


From shade at openjdk.java.net  Tue Sep  8 06:50:34 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Sep 2020 06:50:34 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap
In-Reply-To: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
Message-ID: <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>

On Tue, 8 Sep 2020 03:15:10 GMT, Lin Zang <lzang at openjdk.org> wrote:

> - enable parallel heap inspecton for ShenandoahHeap
>   - preliminary evaluation:
>     Time of jmap histo on (8GB heap with 4GB objects)
>     * before: 5.186s
>     * after : 1.698s

Thanks, this looks interesting.

I need more time to digest this. It feels like we can merge together the parallel (new) and serial (old) heap iteration
code for better maintainability. I could try to do so later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From shade at openjdk.java.net  Tue Sep  8 06:56:30 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Sep 2020 06:56:30 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v3]
In-Reply-To: <IFJ1QBz9-OPXicX_rWNjGurKF4kp6eRDiVlH2rddMmo=.57579ae3-035e-4302-a6fd-aab1130d9648@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <IFJ1QBz9-OPXicX_rWNjGurKF4kp6eRDiVlH2rddMmo=.57579ae3-035e-4302-a6fd-aab1130d9648@github.com>
Message-ID: <t73tiNbzV1H1bNBqovDQoYEPQYEn4Z6215c_RAHf3FE=.1a9eb3ae-4391-4bb4-b3b9-5afd5cc2a180@github.com>

On Tue, 8 Sep 2020 04:38:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a rather large but generally simple cleanup.
>> 
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>   assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>> 
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More missing includes of thread.inline.hpp
>   
>   The fanout for this change is now quite large.

Shenandoah parts still look good. Formally approving.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/37

From david.holmes at oracle.com  Tue Sep  8 07:00:27 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Sep 2020 17:00:27 +1000
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v2]
In-Reply-To: <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <GM65-STpiScugaJ1KHvz7TqN28ooZIKjEZAYr2xYPhY=.e26bf9f9-1c40-43f9-b08f-5b0f94c4818e@github.com>
 <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com>
Message-ID: <5b615b71-9630-ac0a-08be-ce3dd09da7b8@oracle.com>

On 8/09/2020 4:34 pm, Kim Barrett wrote:
>> On Sep 8, 2020, at 12:09 AM, David Holmes <dholmes at openjdk.java.net> wrote:
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   Used static_cast instead of raw C-style cast
>>   Moved inline functions to thread.inline.hpp
>>   Updated #includes to deal with the move to thread.inline.hpp
>>   Updated copyright year where needed.
>>
>> -------------
>>
>> Changes:
>>   - all: https://git.openjdk.java.net/jdk/pull/37/files
>>   - new: https://git.openjdk.java.net/jdk/pull/37/files/b18faad5..da70f804
>>
>> Webrevs:
>> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01
>> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00-01
>>
>>   Stats: 102 lines in 33 files changed: 39 ins; 28 del; 35 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/37.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37
>>
>> PR: https://git.openjdk.java.net/jdk/pull/37
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/thread.hpp
>   507   const JavaThread* as_const_Java_thread() const;
> 
> This missed part of what I'd suggested. I don't think the "const" part
> of the name is needed or helpful.  Just overload as_Java_thread on the
> const-ness of the thread it's being applied to.

I saw that but thought it was a typo as I don't think about overloads in 
terms of const or other modifiers. To me overloads are same named 
methods that differ in arguments (and I'm going to guess that 'this' is 
considered an argument in this context and hence leads to the overload 
based on the const?).

But in addition I wanted to have this say as_const_JavaThread because I 
wanted to clearly distringuish it from as_JavaThread because there is 
only a couple of special cases in the JFR code where this const version 
is needed. If that code were to change and is_const_JavaThread because 
unused, it would be easy to see that.

> There are some situations where there is such an overload pair and it
> is useful to additionally have an explicit const function, but I don't
> think this is one of those.
> 
> ------------------------------------------------------------------------------
> 
> The fannout from putting the conversion functions in thread.inline.hpp seems
> pretty high in the number of files that get touched. Especially since it
> leads to JavaThread::current() and JavaThread::as_CompilerThread() being
> moved. I would have been at least fine with, and probably would prefer,
> having the definitions of as_JavaThread near the old definitions of those
> functions in thread.hpp.

I tried to do the right and obey the "use .inline.hpp for inline 
definitions" rule. But I must confess I was reaching a point where I 
thought this was going too far but it's a good exercise with using git 
and PRs so I don't mind if I back up and take a simpler approach - 
especially as I just discovered more build failures due to missing 
includes. :(

Thanks,
David

> ------------------------------------------------------------------------------
> 

From dholmes at openjdk.java.net  Tue Sep  8 09:34:14 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Sep 2020 09:34:14 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v4]
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <La4I0hMqjUwLIinUjNZlr_WaX19NG7ZMNsqJX-OsBRU=.2911ae56-aa44-4b98-b126-72ac89ac1d13@github.com>

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  This reverts commit 689951708fccd0073873e645bf683bc34b75a772
  This reverts commit da70f8047d3f9c8af9d3eee3b14c71122c5220a0.
  
  Reverting v3 and v2 so that we can take a simpler approach that touches far fewer files.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/37/files
  - new: https://git.openjdk.java.net/jdk/pull/37/files/68995170..202af760

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=02-03

  Stats: 110 lines in 40 files changed: 28 ins; 45 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From ngasson at openjdk.java.net  Tue Sep  8 09:53:13 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 8 Sep 2020 09:53:13 GMT
Subject: RFR: 8252853: AArch64: gc/shenandoah/TestVerifyJCStress.java fails
 intermittently with C1
Message-ID: <i7-Zpw-0mWxGApnLv8Dd1KiaE6IpAKh_Ha-Q81apvhY=.8c460e9a-30f5-4775-b53d-498a7cd04cdc@github.com>

This test fails occasionally when run with -XX:TieredStopAtLevel=1 on
AArch64 with the error

  java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot assign field "prev" because "node" is
  null
      at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
      at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
      at TestVerifyJCStress.main(TestVerifyJCStress.java:109)
      [..snip..]
  Caused by: java.lang.NullPointerException: Cannot assign field "prev" because "node" is null
      at java.base/java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1221)
      at java.base/java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:536)
      at TestVerifyJCStress$Test.WLI_Us(TestVerifyJCStress.java:133)

The particular configuration that fails is -XX:ShenandoahGCMode=iu. In
this mode the Shenandoah C1 CAS implementation calls into
ShenandoahBarrierSetAssembler::storeval_barrier() which performs a VM
leaf call in the slow path (via satb_write_barrier_pre()) but only saves
R0-R4 and V0 (for the interpreter, I guess). Instead it needs to
preserve all the caller saved registers as some of these might hold live
values over the CAS in the C1 generated code.

Tested jtreg hotspot_all_no_apps, jdk_core, plus jcstress with -jvmArgs
'-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'
which would also fail in the same way.

-------------

Commit messages:
 - 8252853: AArch64: gc/shenandoah/TestVerifyJCStress.java fails intermittently with C1

Changes: https://git.openjdk.java.net/jdk/pull/68/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=68&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252853
  Stats: 15 lines in 2 files changed: 5 ins; 7 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/68.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/68/head:pull/68

PR: https://git.openjdk.java.net/jdk/pull/68

From kim.barrett at oracle.com  Tue Sep  8 10:01:24 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 8 Sep 2020 06:01:24 -0400
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v2]
In-Reply-To: <5b615b71-9630-ac0a-08be-ce3dd09da7b8@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <GM65-STpiScugaJ1KHvz7TqN28ooZIKjEZAYr2xYPhY=.e26bf9f9-1c40-43f9-b08f-5b0f94c4818e@github.com>
 <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com>
 <5b615b71-9630-ac0a-08be-ce3dd09da7b8@oracle.com>
Message-ID: <28246A71-A3BD-4240-BED1-6D575B23B851@oracle.com>

> On Sep 8, 2020, at 3:00 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 8/09/2020 4:34 pm, Kim Barrett wrote:
>> [?]

>> src/hotspot/share/runtime/thread.hpp
>>  507   const JavaThread* as_const_Java_thread() const;
>> This missed part of what I'd suggested. I don't think the "const" part
>> of the name is needed or helpful.  Just overload as_Java_thread on the
>> const-ness of the thread it's being applied to.
> 
> I saw that but thought it was a typo

Intentional, not a typo.

> as I don't think about overloads in terms of const or other modifiers. To me overloads are same named methods that differ in arguments (and I'm going to guess that 'this' is considered an argument in this context and hence leads to the overload based on the const?).

That's correct, the function's const qualifier or lack thereof provides
overloading on the corresponding qualification of the 'this' argument.
Such overloading is a "common C++ idiom".

> But in addition I wanted to have this say as_const_JavaThread because I wanted to clearly distringuish it from as_JavaThread because there is only a couple of special cases in the JFR code where this const version is needed. If that code were to change and is_const_JavaThread because unused, it would be easy to see that.

I think those cases are just jfr being better than typical HotSpot code
about const qualifications. I wouldn't be surprised if there were other
places that could benefit from having such an overload pair if we tried
harder to be const-correct. So I would prefer overloading rather than the
odd name.

>> The fannout from putting the conversion functions in thread.inline.hpp seems
>> pretty high in the number of files that get touched. Especially since it
>> leads to JavaThread::current() and JavaThread::as_CompilerThread() being
>> moved. I would have been at least fine with, and probably would prefer,
>> having the definitions of as_JavaThread near the old definitions of those
>> functions in thread.hpp.
> 
> I tried to do the right and obey the "use .inline.hpp for inline definitions" rule. But I must confess I was reaching a point where I thought this was going too far but it's a good exercise with using git and PRs so I don't mind if I back up and take a simpler approach - especially as I just discovered more build failures due to missing includes. :(

I don't think there is such a rule, but that's a deep discussion that goes
far beyond the scope of this change. I think there are problems with how we
are using "inline" files. Stefan Karlsson and I (and others?) had a long
discussion about this a while back, which I can't find right now (drat!).


From shade at openjdk.java.net  Tue Sep  8 10:02:13 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Sep 2020 10:02:13 GMT
Subject: RFR: 8252853: AArch64: gc/shenandoah/TestVerifyJCStress.java
 fails intermittently with C1
In-Reply-To: <i7-Zpw-0mWxGApnLv8Dd1KiaE6IpAKh_Ha-Q81apvhY=.8c460e9a-30f5-4775-b53d-498a7cd04cdc@github.com>
References: <i7-Zpw-0mWxGApnLv8Dd1KiaE6IpAKh_Ha-Q81apvhY=.8c460e9a-30f5-4775-b53d-498a7cd04cdc@github.com>
Message-ID: <iREax1JohCOErtygRO9-p9B4oiNtOUM3MzxSnI9dsNo=.d4c00408-0870-47d0-ab84-9c77d658bb22@github.com>

On Tue, 8 Sep 2020 09:45:29 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This test fails occasionally when run with -XX:TieredStopAtLevel=1 on
> AArch64 with the error
> 
>   java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot assign field "prev" because "node" is
>   null
>       at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>       at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>       at TestVerifyJCStress.main(TestVerifyJCStress.java:109)
>       [..snip..]
>   Caused by: java.lang.NullPointerException: Cannot assign field "prev" because "node" is null
>       at java.base/java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1221)
>       at java.base/java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:536)
>       at TestVerifyJCStress$Test.WLI_Us(TestVerifyJCStress.java:133)
> 
> The particular configuration that fails is -XX:ShenandoahGCMode=iu. In
> this mode the Shenandoah C1 CAS implementation calls into
> ShenandoahBarrierSetAssembler::storeval_barrier() which performs a VM
> leaf call in the slow path (via satb_write_barrier_pre()) but only saves
> R0-R4 and V0 (for the interpreter, I guess). Instead it needs to
> preserve all the caller saved registers as some of these might hold live
> values over the CAS in the C1 generated code.
> 
> Tested jtreg hotspot_all_no_apps, jdk_core, plus jcstress with -jvmArgs
> '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'
> which would also fail in the same way.

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/68

From david.holmes at oracle.com  Tue Sep  8 10:06:02 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Sep 2020 20:06:02 +1000
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v4]
In-Reply-To: <La4I0hMqjUwLIinUjNZlr_WaX19NG7ZMNsqJX-OsBRU=.2911ae56-aa44-4b98-b126-72ac89ac1d13@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <La4I0hMqjUwLIinUjNZlr_WaX19NG7ZMNsqJX-OsBRU=.2911ae56-aa44-4b98-b126-72ac89ac1d13@github.com>
Message-ID: <7c0fd793-e3a0-01df-0efe-0d144e6f20ea@oracle.com>

Just to be clear please wait for v5 to appear before reviewing.

Thanks,
David

On 8/09/2020 7:34 pm, David Holmes wrote:
>> This is a rather large but generally simple cleanup.
>>
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>    assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>>
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>>
>> Thanks,
>> David
> 
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>    This reverts commit 689951708fccd0073873e645bf683bc34b75a772
>    This reverts commit da70f8047d3f9c8af9d3eee3b14c71122c5220a0.
>    
>    Reverting v3 and v2 so that we can take a simpler approach that touches far fewer files.
> 
> -------------
> 
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/37/files
>    - new: https://git.openjdk.java.net/jdk/pull/37/files/68995170..202af760
> 
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=02-03
> 
>    Stats: 110 lines in 40 files changed: 28 ins; 45 del; 37 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/37.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37
> 
> PR: https://git.openjdk.java.net/jdk/pull/37
> 

From ngasson at openjdk.java.net  Tue Sep  8 10:20:18 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 8 Sep 2020 10:20:18 GMT
Subject: Integrated: 8252853: AArch64: gc/shenandoah/TestVerifyJCStress.java
 fails intermittently with C1
In-Reply-To: <i7-Zpw-0mWxGApnLv8Dd1KiaE6IpAKh_Ha-Q81apvhY=.8c460e9a-30f5-4775-b53d-498a7cd04cdc@github.com>
References: <i7-Zpw-0mWxGApnLv8Dd1KiaE6IpAKh_Ha-Q81apvhY=.8c460e9a-30f5-4775-b53d-498a7cd04cdc@github.com>
Message-ID: <uuovon88j_UH51T3HfdQ1VTx-m_kdMvRSj_QUho6DPo=.b9bab0b3-6031-4e44-a542-e73ae270bce7@github.com>

On Tue, 8 Sep 2020 09:45:29 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This test fails occasionally when run with -XX:TieredStopAtLevel=1 on
> AArch64 with the error
> 
>   java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot assign field "prev" because "node" is
>   null
>       at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>       at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>       at TestVerifyJCStress.main(TestVerifyJCStress.java:109)
>       [..snip..]
>   Caused by: java.lang.NullPointerException: Cannot assign field "prev" because "node" is null
>       at java.base/java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1221)
>       at java.base/java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:536)
>       at TestVerifyJCStress$Test.WLI_Us(TestVerifyJCStress.java:133)
> 
> The particular configuration that fails is -XX:ShenandoahGCMode=iu. In
> this mode the Shenandoah C1 CAS implementation calls into
> ShenandoahBarrierSetAssembler::storeval_barrier() which performs a VM
> leaf call in the slow path (via satb_write_barrier_pre()) but only saves
> R0-R4 and V0 (for the interpreter, I guess). Instead it needs to
> preserve all the caller saved registers as some of these might hold live
> values over the CAS in the C1 generated code.
> 
> Tested jtreg hotspot_all_no_apps, jdk_core, plus jcstress with -jvmArgs
> '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'
> which would also fail in the same way.

This pull request has now been integrated.

Changeset: 4fb1980f
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4fb1980f
Stats:     15 lines in 2 files changed: 7 ins; 5 del; 3 mod

8252853: AArch64: gc/shenandoah/TestVerifyJCStress.java fails intermittently with C1

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/68

From dholmes at openjdk.java.net  Tue Sep  8 13:27:17 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Sep 2020 13:27:17 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  This is a simpler approach to use the static_cast. Changes:
  - Change C-style cast to static_cast and move function definitions so this works.
  - Use overloading for const and non-const versions of as_Java_thread().
  - Update copyright years.
  
  Re-testing builds in tiers 1-5.
  
  Thanks.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/37/files
  - new: https://git.openjdk.java.net/jdk/pull/37/files/202af760..50dd8b38

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03-04

  Stats: 31 lines in 12 files changed: 10 ins; 6 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From gnu.andrew at redhat.com  Tue Sep  8 14:11:13 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 8 Sep 2020 15:11:13 +0100
Subject: [RFR] [8u] 8u272-b06 Upstream Sync
In-Reply-To: <360e6306-c213-ce94-7241-f841b81ffdcc@redhat.com>
References: <20200907072946.GF1707023@stopbrexit>
 <360e6306-c213-ce94-7241-f841b81ffdcc@redhat.com>
Message-ID: <20200908141113.GA1846517@stopbrexit>

On 09:58 Mon 07 Sep     , Aleksey Shipilev wrote:
> On 9/7/20 9:29 AM, Andrew Hughes wrote:
> > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/
> > 
> > Merge changesets:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/jaxws/merge.changeset
> 
> Look trivially good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/jdk/merge.changeset
> 
> Looks like TLS 1.3 integration. Seems fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/hotspot/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/langtools/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b06/root/merge.changeset
> 
> Look good.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks, pushed.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 github.com+13698673+zhengyu123 at openjdk.java.net  Tue Sep  8 15:56:01 2020
From: github.com+13698673+zhengyu123 at openjdk.java.net (zhengyu123)
Date: Tue, 8 Sep 2020 15:56:01 GMT
Subject: RFR: 8252695: Shenandoah: clean up Graal enabled/disabled filter
 in tests
In-Reply-To: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>
References: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>
Message-ID: <lZng7RMjYOk0_QS7_8TkQicTM_mQK5bviAPgD3FbblE=.06ce3682-de2f-46f7-83a2-d8eae864cba1@github.com>

On Mon, 7 Sep 2020 11:54:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Drop `!vm.graal.enabled` since it is not required after JDK-8249000.

There are a few more tests, I believe, need to be fixed as well:

gcbasher/TestGCBasherWithShenandoah.java
gclocker/TestGCLockerWithShenandoah.java
gcold/TestGCOldWithShenandoah.java
compiler/c2/aarch64/TestVolatilesShenandoah.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/51

From shade at redhat.com  Tue Sep  8 16:05:56 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 8 Sep 2020 18:05:56 +0200
Subject: [sh/8u] RFR Shenandoah: Backed out weak roots cleaning during
 full gc
In-Reply-To: <b97c34a3-2b6d-0c34-80a0-16c7b98c97f8@redhat.com>
References: <b97c34a3-2b6d-0c34-80a0-16c7b98c97f8@redhat.com>
Message-ID: <20d2d6ec-b74a-49a8-fd35-c1ad38142451@redhat.com>

On 8/28/20 3:38 PM, Zhengyu Gu wrote:
> This patch backout the workaround [1] for Cassandra failure.
> The root cause was fixed by JDK-8248041 [2] and backported in sh/jdk8u,
> therefore, this workaround is no longer needed.
> 
> Webrev:
> http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-backout-weak-roots-cleaning-fullgc/webrev.00/

Looks fine. But there is no repository to push yet, as sh/jdk8 is waiting for CPU release.

-- 
Thanks,
-Aleksey


From shade at openjdk.java.net  Tue Sep  8 16:24:26 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Sep 2020 16:24:26 GMT
Subject: RFR: 8252695: Shenandoah: clean up Graal enabled/disabled filter
 in tests [v2]
In-Reply-To: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>
References: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>
Message-ID: <YkaZplnVyd11GmAy4bDniuFObyJLrV6YAfBTmdvm6XI=.5e69cee7-b666-449b-8433-6fb473354e21@github.com>

> Drop `!vm.graal.enabled` since it is not required after JDK-8249000.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Fix some missing tests too

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/51/files
  - new: https://git.openjdk.java.net/jdk/pull/51/files/68d210a6..a5a5967c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=51&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=51&range=00-01

  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/51/head:pull/51

PR: https://git.openjdk.java.net/jdk/pull/51

From zgu at redhat.com  Tue Sep  8 16:38:09 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 8 Sep 2020 12:38:09 -0400
Subject: [sh/8u] RFR Shenandoah: Backed out weak roots cleaning during
 full gc
In-Reply-To: <20d2d6ec-b74a-49a8-fd35-c1ad38142451@redhat.com>
References: <b97c34a3-2b6d-0c34-80a0-16c7b98c97f8@redhat.com>
 <20d2d6ec-b74a-49a8-fd35-c1ad38142451@redhat.com>
Message-ID: <04081176-e6d7-d303-2553-1b6c708f7d0b@redhat.com>



On 9/8/20 12:05 PM, Aleksey Shipilev wrote:
> On 8/28/20 3:38 PM, Zhengyu Gu wrote:
>> This patch backout the workaround [1] for Cassandra failure.
>> The root cause was fixed by JDK-8248041 [2] and backported in sh/jdk8u,
>> therefore, this workaround is no longer needed.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-backout-weak-roots-cleaning-fullgc/webrev.00/ 
>>
> 
> Looks fine. But there is no repository to push yet, as sh/jdk8 is 
> waiting for CPU release.

Thanks. I will wait till jdk8u open again to push.

-Zhengyu

> 


From shade at openjdk.java.net  Tue Sep  8 17:47:13 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Sep 2020 17:47:13 GMT
Subject: Integrated: 8252695: Shenandoah: clean up Graal enabled/disabled
 filter in tests
In-Reply-To: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>
References: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>
Message-ID: <bdOgg3GEuJRamCzFDb3VuYSZ4gTish6ASQbpwJV68J4=.c5b15634-cb7a-4591-a224-e8d8d2db753a@github.com>

On Mon, 7 Sep 2020 11:54:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Drop `!vm.graal.enabled` since it is not required after JDK-8249000.

This pull request has now been integrated.

Changeset: 91a20ca7
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91a20ca7
Stats:     58 lines in 17 files changed: 0 ins; 0 del; 58 mod

8252695: Shenandoah: clean up Graal enabled/disabled filter in tests

Reviewed-by: zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/51

From zgu at openjdk.java.net  Tue Sep  8 17:47:12 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 8 Sep 2020 17:47:12 GMT
Subject: RFR: 8252695: Shenandoah: clean up Graal enabled/disabled filter
 in tests [v2]
In-Reply-To: <YkaZplnVyd11GmAy4bDniuFObyJLrV6YAfBTmdvm6XI=.5e69cee7-b666-449b-8433-6fb473354e21@github.com>
References: <qbmqVKkbtHNyayJGo-H7zKHu19CIw_sCfVRCMr8P4lk=.143e2eda-d34d-4793-bddd-3dceb32cc039@github.com>
 <YkaZplnVyd11GmAy4bDniuFObyJLrV6YAfBTmdvm6XI=.5e69cee7-b666-449b-8433-6fb473354e21@github.com>
Message-ID: <OGmR6Rh3zTu2X1dKOkB7y0Sj_OO9F4fDo7Ajax4LM9A=.58f43e94-f404-439c-82e1-e75b92ad9548@github.com>

On Tue, 8 Sep 2020 16:24:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Drop `!vm.graal.enabled` since it is not required after JDK-8249000.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some missing tests too

Marked as reviewed by zgu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/51

From iklam at openjdk.java.net  Tue Sep  8 18:40:33 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Sep 2020 18:40:33 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation
Message-ID: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>

This is the same patch as
[8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
published in
[hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).

The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

-------------

Commit messages:
 - 8243208: Clean up JVMFlag implementation

Changes: https://git.openjdk.java.net/jdk/pull/82/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243208
  Stats: 2034 lines in 45 files changed: 695 ins; 516 del; 823 mod
  Patch: https://git.openjdk.java.net/jdk/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk/pull/82

From zgu at redhat.com  Tue Sep  8 19:07:16 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 8 Sep 2020 15:07:16 -0400
Subject: [8] RFR: Shenandoah: JNI weak roots are always cleared before
 Full GC mark
In-Reply-To: <2259ba49-430d-d2c3-c447-1ce347b4aeca@gmail.com>
References: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
 <6a7ced31-4d50-8611-c46c-ff8d8a766503@gmail.com>
 <377ad052-c58c-9348-493c-2d20525b4c8a@redhat.com>
 <2259ba49-430d-d2c3-c447-1ce347b4aeca@gmail.com>
Message-ID: <4e59c85f-2e33-230e-4493-192e15ed094a@redhat.com>

Hi Kornel,

On 9/7/20 1:08 PM, Kornel Pal wrote:
> Hi Zhengyu,
> 
> Thank you for getting back to me and preparing the change this quickly.
> 
> I'm looking forward to see the change in the nightly builds.
> 

Thanks for reporting.

The fix is reviewed and ready for pushing.

However, current shenandoah/jdk8 repo is closed for upcoming 
integration. I will push the change once the repo is reopen.

-Zhengyu

> Thank you,
> Kornel
> 
> On 2020-08-28. 14:36, Zhengyu Gu wrote:
>> Hi Kornel,
>>
>> Yes, I will RFR to backout this workaround.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>> On 8/28/20 12:52 AM, Kornel Pal wrote:
>>> Hi Aleksey,
>>>
>>> Thank you very much for all the dedicated work on Shenandoah GC, it 
>>> really is useful.
>>>
>>> I wonder whether this workaround could safely be removed, now that 
>>> JDK-8248041 was backported to 8u.
>>>
>>> Thank you,
>>> Kornel
>>>
>>> On 2020-06-22 19:39, 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 coleenp at openjdk.java.net  Tue Sep  8 19:10:16 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 8 Sep 2020 19:10:16 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
Message-ID: <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com>

On Tue, 8 Sep 2020 13:27:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a rather large but generally simple cleanup.
>> 
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>   assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>> 
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   This is a simpler approach to use the static_cast. Changes:
>   - Change C-style cast to static_cast and move function definitions so this works.
>   - Use overloading for const and non-const versions of as_Java_thread().
>   - Update copyright years.
>   
>   Re-testing builds in tiers 1-5.
>   
>   Thanks.

Marked as reviewed by coleenp (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From coleenp at openjdk.java.net  Tue Sep  8 19:10:16 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 8 Sep 2020 19:10:16 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
 <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com>
Message-ID: <sludFBKLDzyAiJM3_iJvqCazlZe0Eu2vENR1Isgyq4U=.e0cde86f-53f2-486e-8658-c1c1399b6fda@github.com>

On Tue, 8 Sep 2020 19:07:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   This is a simpler approach to use the static_cast. Changes:
>>   - Change C-style cast to static_cast and move function definitions so this works.
>>   - Use overloading for const and non-const versions of as_Java_thread().
>>   - Update copyright years.
>>   
>>   Re-testing builds in tiers 1-5.
>>   
>>   Thanks.
>
> Marked as reviewed by coleenp (Reviewer).

I'll look at v5 diffs but if I don't, this is still reviewed.  Nice cleanup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From david.holmes at oracle.com  Tue Sep  8 22:05:51 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Sep 2020 08:05:51 +1000
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <sludFBKLDzyAiJM3_iJvqCazlZe0Eu2vENR1Isgyq4U=.e0cde86f-53f2-486e-8658-c1c1399b6fda@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
 <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com>
 <sludFBKLDzyAiJM3_iJvqCazlZe0Eu2vENR1Isgyq4U=.e0cde86f-53f2-486e-8658-c1c1399b6fda@github.com>
Message-ID: <d6dd6757-e8bf-f935-e4f1-0d7f3da90132@oracle.com>

Thanks for the review Coleen!

David

On 9/09/2020 5:10 am, Coleen Phillimore wrote:
> On Tue, 8 Sep 2020 19:07:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    This is a simpler approach to use the static_cast. Changes:
>>>    - Change C-style cast to static_cast and move function definitions so this works.
>>>    - Use overloading for const and non-const versions of as_Java_thread().
>>>    - Update copyright years.
>>>    
>>>    Re-testing builds in tiers 1-5.
>>>    
>>>    Thanks.
>>
>> Marked as reviewed by coleenp (Reviewer).
> 
> I'll look at v5 diffs but if I don't, this is still reviewed.  Nice cleanup.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/37
> 

From adityam at openjdk.java.net  Tue Sep  8 22:14:55 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Tue, 8 Sep 2020 22:14:55 GMT
Subject: RFR: 8240751: Shenandoah: fold ShenandoahTracer definition [v2]
In-Reply-To: <he1MA4ldvIvUr0VMk2XI26PCvX5loR7g9nVThi8HNLM=.93237f05-2c1a-46c1-884e-7fb0ae0676e4@github.com>
References: <ZAiMCKzw5hzLzZk-fAvD8K6P3kOZ2-ZrwZ9jVgesaQI=.3fa0841d-612f-4198-abf6-c2ca6b513535@github.com>
 <he1MA4ldvIvUr0VMk2XI26PCvX5loR7g9nVThi8HNLM=.93237f05-2c1a-46c1-884e-7fb0ae0676e4@github.com>
Message-ID: <SBr_yLA-brVMxTZDSBtGb9KlsDuT89SjyU3a2vXXrLY=.9e89fcf1-9e76-443c-baf3-b742c8609b9d@github.com>

On Mon, 7 Sep 2020 13:49:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently, we have `shenandoahTracer.hpp` with a sole definition:
>> class ShenandoahTracer : public GCTracer {
>> public:
>>   ShenandoahTracer() : GCTracer(Shenandoah) {}
>> };
>> 
>> This can be folded near the only use at `shenandoahCollectorPolicy.hpp`.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leftover include of deleted file

Not a reviewer, but this looks good to me.

-------------

Marked as reviewed by adityam (Author).

PR: https://git.openjdk.java.net/jdk/pull/55

From dholmes at openjdk.java.net  Wed Sep  9 00:57:31 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Sep 2020 00:57:31 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <AwyLf7Pm6568ujZBkiEMQ2tMVNLq_gRFz2QxSV5_41s=.5846c596-9657-4d3f-8120-a9f7c3425c00@github.com>

On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

One query below and a couple of style nits. Otherwise LGTM!

src/hotspot/share/runtime/flags/jvmFlagConstraintList.cpp line 220:

> 218:
> 219:   bool status = true;
> 220:   for (int i=0; i<NUM_JVMFlagsEnum; i++) {

Spaces around binary operators please.

src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 57:

> 55: void* JVMFlagLimit::constraint_func() const {
> 56:   int i = _constraint_func;
> 57:   assert(0 <= i && i <NUM_JVMFlagConstraintsEnum, "sanity");

Space after < please

src/hotspot/share/runtime/flags/jvmFlagLimit.hpp line 98:

> 96:   }
> 97:
> 98: #define AS_TYPED_LIMIT(type) inline JVMTypedFlagLimit<type>* as_ ## type() const { return
> (JVMTypedFlagLimit<type>*)this; }

Is it possible to use static_cast here rather than C-style cast?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/82

From lzang at openjdk.java.net  Wed Sep  9 03:02:57 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 9 Sep 2020 03:02:57 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap
In-Reply-To: <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>
Message-ID: <KybrQhWK_lSIFHMxPpyvr2--klhFMsAebgnsjVnU58I=.2d6e3024-f4ba-4814-b13d-a29226eba551@github.com>

On Tue, 8 Sep 2020 06:48:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> - enable parallel heap inspecton for ShenandoahHeap
>>   - preliminary evaluation:
>>     Time of jmap histo on (8GB heap with 4GB objects)
>>     * before: 5.186s
>>     * after : 1.698s
>
> Thanks, this looks interesting.
> 
> I need more time to digest this. It feels like we can merge together the parallel (new) and serial (old) heap iteration
> code for better maintainability. I could try to do so later.

Thanks @shipilev? This is shenandoah support based on parallel heap inspection enabling in serviceability (tracked with
https://bugs.openjdk.java.net/browse/JDK-8215624). hope it is helpful for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From kim.barrett at oracle.com  Wed Sep  9 03:26:56 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 8 Sep 2020 23:26:56 -0400
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v4]
In-Reply-To: <7c0fd793-e3a0-01df-0efe-0d144e6f20ea@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <La4I0hMqjUwLIinUjNZlr_WaX19NG7ZMNsqJX-OsBRU=.2911ae56-aa44-4b98-b126-72ac89ac1d13@github.com>
 <7c0fd793-e3a0-01df-0efe-0d144e6f20ea@oracle.com>
Message-ID: <D16D2F52-4D77-441F-A7A7-FDCF46C52712@oracle.com>

> On Sep 8, 2020, at 6:06 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Just to be clear please wait for v5 to appear before reviewing.

I think you meant ?v4?, i.e. the 5th zero-based version?


From kim.barrett at oracle.com  Wed Sep  9 03:30:48 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 8 Sep 2020 23:30:48 -0400
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
Message-ID: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com>

> On Sep 8, 2020, at 9:27 AM, David Holmes <dholmes at openjdk.java.net> wrote:
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>  This is a simpler approach to use the static_cast. Changes:
>  - Change C-style cast to static_cast and move function definitions so this works.
>  - Use overloading for const and non-const versions of as_Java_thread().
>  - Update copyright years.
> 
>  Re-testing builds in tiers 1-5.
> 
>  Thanks.
> 
> -------------
> 
> Changes:
>  - all: https://git.openjdk.java.net/jdk/pull/37/files
>  - new: https://git.openjdk.java.net/jdk/pull/37/files/202af760..50dd8b38
> 
> Webrevs:
> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04
> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03-04
> 
>  Stats: 31 lines in 12 files changed: 10 ins; 6 del; 15 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37
> 
> PR: https://git.openjdk.java.net/jdk/pull/37

I reviewed all of v4, not just the gc parts this time.

------------------------------------------------------------------------------
src/hotspot/share/classfile/systemDictionary.cpp

The block from line 1646-1655 seems to be misindented.  And was before too.

------------------------------------------------------------------------------
src/hotspot/share/gc/shared/barrierSet.cpp
[removed]
45   assert(Thread::current()->is_Java_thread(),
46          "Expected main thread to be a JavaThread");

This was an intentional redundancy with the following JavaThread::current(),
to provide a more informative error message.

[Sorry about missing this on my first pass through.]

------------------------------------------------------------------------------
src/hotspot/share/jvmci/jvmciEnv.cpp
 243 void JVMCIEnv::describe_pending_exception(bool clear) {
 244   JavaThread* THREAD = JavaThread::current();

This change looks suspicious.  The old code used Thread::current() here and
later cast to a JavaThread*.  But that use and cast is conditional, and
might not be executed at all, depending on the result of !is_hotspot().  So
previously if !is_hotspot() then the current thread could be a non-JavaThread.

(At least locally; there could be things being called in the !is_hotspot()
case that also require a current JavaThread.)

It also looks like the THREAD variable could be eliminated and it's one use
changed to JavaThread::current().

------------------------------------------------------------------------------
src/hotspot/share/prims/jvm.cpp
992   assert(THREAD->is_Java_thread(), "must be a JavaThread");

It's not obvious why this assert is being removed.

------------------------------------------------------------------------------
src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp

63 #define assert_Java_thread() \
 64   assert(Thread::current()->is_Java_thread(), "precondition")
 65 
 66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
 67   assert_Java_thread();
 68   MonitorLocker ml(monitor());

=>

63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
 64   MonitorLocker ml(JavaThread::current(), monitor());

and related later changes in this file.

I prefer the original code, which intentionally made the precondition check
explicit.

[Sorry about missing this on my first pass through.]

------------------------------------------------------------------------------
src/hotspot/share/runtime/objectMonitor.cpp
1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) {
1256   Thread * const Self = THREAD;
1257   JavaThread * jt = Self->as_Java_thread();

The only use of Self could just be THREAD, which is also used in this
function. And I don't see any references to jt at all here.  Maybe that
should just be an `assert(THREAD->is_Java_thread(), "precondition");`.

Hm, there are other functions in this file that have a peculiar mix of
Self/THREAD usage and bound but unused jt.

Cleaning that up should probably be a separate task; this changeset is
already quite big enough!

------------------------------------------------------------------------------
src/hotspot/share/services/management.cpp
2074 if (thread_id == 0) { // current thread
2075     return thread->cooked_allocated_bytes();

Indentation got messed up.

------------------------------------------------------------------------------

It seems like there are some places where if a function parameter were
JavaThread* rather than Thread* then there wouldn't need to be a call to
as_Java_thread. That is, use the type system to make sure the types are
correct, rather than a debug-only runtime check. But that's something to
look at as a followup.

------------------------------------------------------------------------------



From iklam at openjdk.java.net  Wed Sep  9 04:56:25 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 04:56:25 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation
In-Reply-To: <AwyLf7Pm6568ujZBkiEMQ2tMVNLq_gRFz2QxSV5_41s=.5846c596-9657-4d3f-8120-a9f7c3425c00@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <AwyLf7Pm6568ujZBkiEMQ2tMVNLq_gRFz2QxSV5_41s=.5846c596-9657-4d3f-8120-a9f7c3425c00@github.com>
Message-ID: <sPTLF5ajYEUp86Wkh1dQJXE_UiXyBiGZMX1-uPpkajY=.0acb6ac3-add0-4b5e-b39a-9b3f7f5dd545@github.com>

On Wed, 9 Sep 2020 00:48:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
>> same patch as
>> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
>> published in
>> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
>> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.
>
> src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 57:
> 
>> 55: void* JVMFlagLimit::constraint_func() const {
>> 56:   int i = _constraint_func;
>> 57:   assert(0 <= i && i <NUM_JVMFlagConstraintsEnum, "sanity");
> 
> Space after < please

Fixed.

> src/hotspot/share/runtime/flags/jvmFlagConstraintList.cpp line 220:
> 
>> 218:
>> 219:   bool status = true;
>> 220:   for (int i=0; i<NUM_JVMFlagsEnum; i++) {
> 
> Spaces around binary operators please.

Fixed.

> src/hotspot/share/runtime/flags/jvmFlagLimit.hpp line 98:
> 
>> 96:   }
>> 97:
>> 98: #define AS_TYPED_LIMIT(type) inline JVMTypedFlagLimit<type>* as_ ## type() const { return
>> (JVMTypedFlagLimit<type>*)this; }
> 
> Is it possible to use static_cast here rather than C-style cast?

I tried but got this error:

invalid static_cast from type 'const JVMFlagLimit*' to type 'const JVMTypedFlagLimit<unsigned int>*'

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 05:05:39 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 05:05:39 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v2]
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <hCEBSx618Gw9-mMckespYx_E030b0UQZemgxxQ7CJTA=.f09be9de-d74d-4607-84eb-5b7216efbd3b@github.com>

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(),
  (d) removed product_rw which is not used by any flags

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/82/files
  - new: https://git.openjdk.java.net/jdk/pull/82/files/d85cbd63..2e387eb4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=00-01

  Stats: 160 lines in 9 files changed: 75 ins; 32 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 05:19:06 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 05:19:06 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v2]
In-Reply-To: <AwyLf7Pm6568ujZBkiEMQ2tMVNLq_gRFz2QxSV5_41s=.5846c596-9657-4d3f-8120-a9f7c3425c00@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <AwyLf7Pm6568ujZBkiEMQ2tMVNLq_gRFz2QxSV5_41s=.5846c596-9657-4d3f-8120-a9f7c3425c00@github.com>
Message-ID: <PtMoDE2QcvxXQnJIFpSYyqvTuv5PHETfallTAsSfi_M=.8d24999c-097b-4c72-97af-2452d9454298@github.com>

On Wed, 9 Sep 2020 00:55:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(),
>>   (d) removed product_rw which is not used by any flags
>
> One query below and a couple of style nits. Otherwise LGTM!

Re: [Gerard Ziemski's comments on
hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042868.html):

> (1) The API JVMFlagLimit::get_constraint(flag) says ?constraint?, but it returns JVMFlagLimit* using different names
> for the same thing - one calls it ?limit", the other uses ?constraint?.

JVMFlagLimit is used for both constraints and ranges. I updated the comments:
// A JVMFlagLimit is created for each JVMFlag that has a range() and/or constraint() in its declaration in
// the globals_xxx.hpp file.
//
// To query the range information of a JVMFlag:
//     JVMFlagLimit::get_range(JVMFlag*)
//     JVMFlagLimit::get_range_at(int flag_enum)
// If the given flag doesn't have a range, NULL is returned.
//
// To query the constraint information of a JVMFlag:
//     JVMFlagLimit::get_constraint(JVMFlag*)
//     JVMFlagLimit::get_constraint_at(int flag_enum)
// If the given flag doesn't have a constraint, NULL is returned.

> (3) Isn?t there a better way to treat the special cases in "JVMFlagRangeList::print?, without explicitly checking for
> hardcoded function pointers? Or is it just not worth the effort, with only 2 such cases for now?

So far there are only 2 cases so I think the explicit checking may be enough. If we have more cases in the future we
can have a more general solution.

> (5) I'm not sure how others feel about it, but I think I personally would find it helpful for macros like
> ?DEFINE_RANGE_CHECK? to see a comment with a concrete example of macro expansion for some flag, just to see what it
> works out to be.

I think this macro is fairly easy to read, so adding an expanded example may not have much benefit:

#define DEFINE_RANGE_CHECK(T)                                                            \
JVMFlag::Error JVMFlagRangeChecker::check_ ## T(T value, bool verbose) const {           \
  assert(exists(), "must be");                                                           \
  JVMFlagRange_ ## T range(_flag, _limit->as_ ## T()->min(), _limit->as_ ## T()->max()); \
  return range.check_ ## T(value, verbose);                                              \
}

In [JDK-8081833](https://bugs.openjdk.java.net/browse/JDK-8081833), I plan to use templates to replaces the nearly
identical code in jvmFlagRangeList.cpp/jvmFlagConstraintList.cpp, and these macros should go away.

(I fixed other minor nits found by Gerard.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From kim.barrett at oracle.com  Wed Sep  9 05:27:14 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 9 Sep 2020 01:27:14 -0400
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
 <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com>
Message-ID: <E21D3933-013E-4740-A517-3E0EDCA6220F@oracle.com>

> On Sep 8, 2020, at 11:30 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> I reviewed all of v4, not just the gc parts this time.

I guess it was v5 I was reviewing.  There seems to be an inconsistency in numbering.


From iklam at openjdk.java.net  Wed Sep  9 06:28:59 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 06:28:59 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed JVMFlag::is_writeable()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/82/files
  - new: https://git.openjdk.java.net/jdk/pull/82/files/2e387eb4..10246284

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk/pull/82

From david.holmes at oracle.com  Wed Sep  9 07:08:00 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Sep 2020 17:08:00 +1000
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
 <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com>
Message-ID: <d740a0fd-4c70-9113-cab4-7855d18ce5c5@oracle.com>

Hi Kim,

On 9/09/2020 1:30 pm, Kim Barrett wrote:
>> On Sep 8, 2020, at 9:27 AM, David Holmes <dholmes at openjdk.java.net> wrote:
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   This is a simpler approach to use the static_cast. Changes:
>>   - Change C-style cast to static_cast and move function definitions so this works.
>>   - Use overloading for const and non-const versions of as_Java_thread().
>>   - Update copyright years.
>>
>>   Re-testing builds in tiers 1-5.
>>
>>   Thanks.
>>
>> -------------
>>
>> Changes:
>>   - all: https://git.openjdk.java.net/jdk/pull/37/files
>>   - new: https://git.openjdk.java.net/jdk/pull/37/files/202af760..50dd8b38
>>
>> Webrevs:
>> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04
>> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03-04
>>
>>   Stats: 31 lines in 12 files changed: 10 ins; 6 del; 15 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/37.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37
>>
>> PR: https://git.openjdk.java.net/jdk/pull/37
> 
> I reviewed all of v4, not just the gc parts this time.

Thank you.

Note that I've been using the version as given in the email subject 
(i.e. v5 here) not the "range" value (04 here) listed in the webrev 
links. Sorry for any confusion.

> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/systemDictionary.cpp
> 
> The block from line 1646-1655 seems to be misindented.  And was before too.

Fixed.

> ------------------------------------------------------------------------------
> src/hotspot/share/gc/shared/barrierSet.cpp
> [removed]
> 45   assert(Thread::current()->is_Java_thread(),
> 46          "Expected main thread to be a JavaThread");
> 
> This was an intentional redundancy with the following JavaThread::current(),
> to provide a more informative error message.
> 
> [Sorry about missing this on my first pass through.]

Reverted.

> ------------------------------------------------------------------------------
> src/hotspot/share/jvmci/jvmciEnv.cpp
>   243 void JVMCIEnv::describe_pending_exception(bool clear) {
>   244   JavaThread* THREAD = JavaThread::current();
> 
> This change looks suspicious.  The old code used Thread::current() here and
> later cast to a JavaThread*.  But that use and cast is conditional, and
> might not be executed at all, depending on the result of !is_hotspot().  So
> previously if !is_hotspot() then the current thread could be a non-JavaThread.
> 
> (At least locally; there could be things being called in the !is_hotspot()
> case that also require a current JavaThread.)

Yes - if you look at JNIAccessMark it manifests JavaThread::current() by 
default.

> 
> It also looks like the THREAD variable could be eliminated and it's one use
> changed to JavaThread::current().

Or I can keep it and also use it for the JNIAccessMark constructor.

> ------------------------------------------------------------------------------
> src/hotspot/share/prims/jvm.cpp
> 992   assert(THREAD->is_Java_thread(), "must be a JavaThread");
> 
> It's not obvious why this assert is being removed.

The fact THREAD must be a JavaThread is already established by the 
JVM_ENTRY calls that then invoke this local method.

> ------------------------------------------------------------------------------
> src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp
> 
> 63 #define assert_Java_thread() \
>   64   assert(Thread::current()->is_Java_thread(), "precondition")
>   65
>   66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
>   67   assert_Java_thread();
>   68   MonitorLocker ml(monitor());
> 
> =>
> 
> 63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
>   64   MonitorLocker ml(JavaThread::current(), monitor());
> 
> and related later changes in this file.
> 
> I prefer the original code, which intentionally made the precondition check
> explicit.

The same precondition is already present in the use of 
JavaThread::current(). Is that not explicit enough? Plus the old code 
will manifest the current thread twice in debug builds. Cleaning up this 
kind of redundancy is one of the key aims here. :(

> 
> [Sorry about missing this on my first pass through.]
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/objectMonitor.cpp
> 1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) {
> 1256   Thread * const Self = THREAD;
> 1257   JavaThread * jt = Self->as_Java_thread();
> 
> The only use of Self could just be THREAD, which is also used in this
> function. And I don't see any references to jt at all here.  Maybe that
> should just be an `assert(THREAD->is_Java_thread(), "precondition");`.
> 
> Hm, there are other functions in this file that have a peculiar mix of
> Self/THREAD usage and bound but unused jt.
> 
> Cleaning that up should probably be a separate task; this changeset is
> already quite big enough!

Right, I tried to avoid the temptation of dealing with the 
Self/THREAD/jt mess in this change. I have another RFE filed that will 
do further cleanup here:

https://bugs.openjdk.java.net/browse/JDK-8252685

> ------------------------------------------------------------------------------
> src/hotspot/share/services/management.cpp
> 2074 if (thread_id == 0) { // current thread
> 2075     return thread->cooked_allocated_bytes();
> 
> Indentation got messed up.

Fixed. (I must remember to try the emacs fix to handle the JVM_ENTRY and 
other macros.)

> ------------------------------------------------------------------------------
> 
> It seems like there are some places where if a function parameter were
> JavaThread* rather than Thread* then there wouldn't need to be a call to
> as_Java_thread. That is, use the type system to make sure the types are
> correct, rather than a debug-only runtime check. But that's something to
> look at as a followup.

Yep - that same RFE:

https://bugs.openjdk.java.net/browse/JDK-8252685

Thanks,
David
-----

> ------------------------------------------------------------------------------
> 
> 

From dholmes at openjdk.java.net  Wed Sep  9 07:13:53 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Sep 2020 07:13:53 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v6]
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <VJKRNK5NL18aG_IsdXFUSw2sHHtjls_KaL777MJIwFk=.09b50c8a-3e64-4672-bb24-e6ac486c33c7@github.com>

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixups from Kim's review.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/37/files
  - new: https://git.openjdk.java.net/jdk/pull/37/files/50dd8b38..9426d53b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04-05

  Stats: 15 lines in 4 files changed: 2 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From kim.barrett at oracle.com  Wed Sep  9 09:09:12 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 9 Sep 2020 05:09:12 -0400
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <d740a0fd-4c70-9113-cab4-7855d18ce5c5@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
 <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com>
 <d740a0fd-4c70-9113-cab4-7855d18ce5c5@oracle.com>
Message-ID: <E00020BB-2342-4B1D-A6B8-FF8C19213FA8@oracle.com>

Hi David.  Thanks for clarifying some bits I was confused abut.

>> src/hotspot/share/jvmci/jvmciEnv.cpp
>>  243 void JVMCIEnv::describe_pending_exception(bool clear) {
>>  244   JavaThread* THREAD = JavaThread::current();
>> This change looks suspicious.  The old code used Thread::current() here and
>> later cast to a JavaThread*.  But that use and cast is conditional, and
>> might not be executed at all, depending on the result of !is_hotspot().  So
>> previously if !is_hotspot() then the current thread could be a non-JavaThread.
>> (At least locally; there could be things being called in the !is_hotspot()
>> case that also require a current JavaThread.)
> 
> Yes - if you look at JNIAccessMark it manifests JavaThread::current() by default.
> 
>> It also looks like the THREAD variable could be eliminated and it's one use
>> changed to JavaThread::current().
> 
> Or I can keep it and also use it for the JNIAccessMark constructor.

I see; good.

>> src/hotspot/share/prims/jvm.cpp
>> 992   assert(THREAD->is_Java_thread(), "must be a JavaThread");
>> It's not obvious why this assert is being removed.
> 
> The fact THREAD must be a JavaThread is already established by the JVM_ENTRY calls that then invoke this local method.

Right.  I keep forgetting which of these macros does what with which kinds of threads.

>> src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp
>> 63 #define assert_Java_thread() \
>>  64   assert(Thread::current()->is_Java_thread(), "precondition")
>>  65
>>  66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
>>  67   assert_Java_thread();
>>  68   MonitorLocker ml(monitor());
>> =>
>> 63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
>>  64   MonitorLocker ml(JavaThread::current(), monitor());
>> and related later changes in this file.
>> I prefer the original code, which intentionally made the precondition check
>> explicit.
> 
> The same precondition is already present in the use of JavaThread::current(). Is that not explicit enough? Plus the old code will manifest the current thread twice in debug builds. Cleaning up this kind of redundancy is one of the key aims here. :(

I'm not that concerned by a little redundant work in a debug build. I think
the explicit assert is clearer here. It removes the question for the future
reader of why it's asking for a JavaThread for the mutex locker, when any
thread can be used there. It's not obvious that the reason is to get the
associated assertion.

>> src/hotspot/share/runtime/objectMonitor.cpp
>> 1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) {
>> 1256   Thread * const Self = THREAD;
>> 1257   JavaThread * jt = Self->as_Java_thread();
>> The only use of Self could just be THREAD, which is also used in this
>> function. And I don't see any references to jt at all here.  Maybe that
>> should just be an `assert(THREAD->is_Java_thread(), "precondition");`.
>> Hm, there are other functions in this file that have a peculiar mix of
>> Self/THREAD usage and bound but unused jt.
>> Cleaning that up should probably be a separate task; this changeset is
>> already quite big enough!
> 
> Right, I tried to avoid the temptation of dealing with the Self/THREAD/jt mess in this change. I have another RFE filed that will do further cleanup here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8252685

Good.



From zgu at openjdk.java.net  Wed Sep  9 12:06:07 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 9 Sep 2020 12:06:07 GMT
Subject: RFR: 8240751: Shenandoah: fold ShenandoahTracer definition [v2]
In-Reply-To: <he1MA4ldvIvUr0VMk2XI26PCvX5loR7g9nVThi8HNLM=.93237f05-2c1a-46c1-884e-7fb0ae0676e4@github.com>
References: <ZAiMCKzw5hzLzZk-fAvD8K6P3kOZ2-ZrwZ9jVgesaQI=.3fa0841d-612f-4198-abf6-c2ca6b513535@github.com>
 <he1MA4ldvIvUr0VMk2XI26PCvX5loR7g9nVThi8HNLM=.93237f05-2c1a-46c1-884e-7fb0ae0676e4@github.com>
Message-ID: <rvw9ThBkEP7XRrfG7FNUGaTAfmgRiugw4J0X6qRFe9w=.a0838983-5cbb-4976-95b4-24f46f6f351c@github.com>

On Mon, 7 Sep 2020 13:49:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently, we have `shenandoahTracer.hpp` with a sole definition:
>> class ShenandoahTracer : public GCTracer {
>> public:
>>   ShenandoahTracer() : GCTracer(Shenandoah) {}
>> };
>> 
>> This can be folded near the only use at `shenandoahCollectorPolicy.hpp`.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leftover include of deleted file

Marked as reviewed by zgu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/55

From shade at openjdk.java.net  Wed Sep  9 12:13:26 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 9 Sep 2020 12:13:26 GMT
Subject: Integrated: 8240751: Shenandoah: fold ShenandoahTracer definition
In-Reply-To: <ZAiMCKzw5hzLzZk-fAvD8K6P3kOZ2-ZrwZ9jVgesaQI=.3fa0841d-612f-4198-abf6-c2ca6b513535@github.com>
References: <ZAiMCKzw5hzLzZk-fAvD8K6P3kOZ2-ZrwZ9jVgesaQI=.3fa0841d-612f-4198-abf6-c2ca6b513535@github.com>
Message-ID: <1XBjDPUingq2_aWrbMR6bDsjqsRQrId-XHnEVpKOF18=.4af6a4d3-a325-4e38-a5f7-43b4481b339e@github.com>

On Mon, 7 Sep 2020 13:04:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, we have `shenandoahTracer.hpp` with a sole definition:
> class ShenandoahTracer : public GCTracer {
> public:
>   ShenandoahTracer() : GCTracer(Shenandoah) {}
> };
> 
> This can be folded near the only use at `shenandoahCollectorPolicy.hpp`.

This pull request has now been integrated.

Changeset: 382b8fed
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/382b8fed
Stats:     42 lines in 2 files changed: 36 ins; 6 del; 0 mod

8240751: Shenandoah: fold ShenandoahTracer definition

Reviewed-by: adityam, zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/55

From dholmes at openjdk.java.net  Wed Sep  9 12:48:11 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Sep 2020 12:48:11 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v7]
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Reverted to the original code as the explicit assertion is preferred.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/37/files
  - new: https://git.openjdk.java.net/jdk/pull/37/files/9426d53b..50575621

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=05-06

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From david.holmes at oracle.com  Wed Sep  9 12:50:18 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Sep 2020 22:50:18 +1000
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v5]
In-Reply-To: <E00020BB-2342-4B1D-A6B8-FF8C19213FA8@oracle.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <Vb_az98zsYzBxvsU8ux-ktx-0S38ZXj860sJ1U2WLTc=.9ed11677-4285-4793-8b27-f3bccdbb8077@github.com>
 <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com>
 <d740a0fd-4c70-9113-cab4-7855d18ce5c5@oracle.com>
 <E00020BB-2342-4B1D-A6B8-FF8C19213FA8@oracle.com>
Message-ID: <8eacd775-d484-eb4d-d18e-44a36d632ea1@oracle.com>

Trimming ...

On 9/09/2020 7:09 pm, Kim Barrett wrote:
>>> src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp
>>> 63 #define assert_Java_thread() \
>>>   64   assert(Thread::current()->is_Java_thread(), "precondition")
>>>   65
>>>   66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
>>>   67   assert_Java_thread();
>>>   68   MonitorLocker ml(monitor());
>>> =>
>>> 63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) {
>>>   64   MonitorLocker ml(JavaThread::current(), monitor());
>>> and related later changes in this file.
>>> I prefer the original code, which intentionally made the precondition check
>>> explicit.
>>
>> The same precondition is already present in the use of JavaThread::current(). Is that not explicit enough? Plus the old code will manifest the current thread twice in debug builds. Cleaning up this kind of redundancy is one of the key aims here. :(
> 
> I'm not that concerned by a little redundant work in a debug build. I think
> the explicit assert is clearer here. It removes the question for the future
> reader of why it's asking for a JavaThread for the mutex locker, when any
> thread can be used there. It's not obvious that the reason is to get the
> associated assertion.

I personally think that the use of JavaThread::current() makes a clear 
statement that a JavaThread is expected here, but I have reverted the 
change.

Thanks,
David
-----

> 
>>> src/hotspot/share/runtime/objectMonitor.cpp
>>> 1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) {
>>> 1256   Thread * const Self = THREAD;
>>> 1257   JavaThread * jt = Self->as_Java_thread();
>>> The only use of Self could just be THREAD, which is also used in this
>>> function. And I don't see any references to jt at all here.  Maybe that
>>> should just be an `assert(THREAD->is_Java_thread(), "precondition");`.
>>> Hm, there are other functions in this file that have a peculiar mix of
>>> Self/THREAD usage and bound but unused jt.
>>> Cleaning that up should probably be a separate task; this changeset is
>>> already quite big enough!
>>
>> Right, I tried to avoid the temptation of dealing with the Self/THREAD/jt mess in this change. I have another RFE filed that will do further cleanup here:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8252685
> 
> Good.
> 
> 

From dholmes at openjdk.java.net  Wed Sep  9 13:23:48 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Sep 2020 13:23:48 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
Message-ID: <LsmLtYObTVpq4R5gBHeAUb1zP_EDOluIZeFxUY0R9A8=.9f67ecbe-65cd-45c8-b4d5-87ba2cd90dbf@github.com>

On Wed, 9 Sep 2020 06:28:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
>> same patch as
>> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
>> published in
>> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
>> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed JVMFlag::is_writeable()

Updates seem okay. One query below.

src/hotspot/share/runtime/flags/jvmFlag.cpp line 266:

> 264:
> 265: bool JVMFlag::is_writeable() const {
> 266:   return is_manageable();

Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags
writeable in non-product builds?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/82

From kbarrett at openjdk.java.net  Wed Sep  9 14:08:42 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Sep 2020 14:08:42 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v7]
In-Reply-To: <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>
Message-ID: <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com>

On Wed, 9 Sep 2020 12:48:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a rather large but generally simple cleanup.
>> 
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>   assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>> 
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted to the original code as the explicit assertion is preferred.

Marked as reviewed by kbarrett (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From coleenp at openjdk.java.net  Wed Sep  9 14:20:02 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 9 Sep 2020 14:20:02 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
Message-ID: <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>

On Wed, 9 Sep 2020 06:28:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
>> same patch as
>> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
>> published in
>> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
>> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed JVMFlag::is_writeable()

Marked as reviewed by coleenp (Reviewer).

src/hotspot/share/runtime/flags/jvmFlag.hpp line 36:

> 34: typedef const char* (*RangeStrFunc)(void);
> 35:
> 36: struct JVMFlag {

I'm still getting used to git diffs, but can you change this from struct to class?  Because it looks like it does have
private and public sections.

src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 102:

> 100:   static constexpr const JVMFlagLimit* get_limit(const JVMTypedFlagLimit<T>* p, int dummy, ConstraintMarker
> dummy2, short func, int phase, T min, T max) { 101:     return p;
> 102:   }

Instead of the 'no_limit' functions, could you have get_limit have PRODUCT_RETURN(NULL) ?  Otherwise, fine to get the
macros working.

src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 44:

> 42:     }
> 43:     return h;
> 44:   }

Can this function just call hash_code(s, strlen(s)) ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From coleenp at openjdk.java.net  Wed Sep  9 14:20:03 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 9 Sep 2020 14:20:03 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <LsmLtYObTVpq4R5gBHeAUb1zP_EDOluIZeFxUY0R9A8=.9f67ecbe-65cd-45c8-b4d5-87ba2cd90dbf@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <LsmLtYObTVpq4R5gBHeAUb1zP_EDOluIZeFxUY0R9A8=.9f67ecbe-65cd-45c8-b4d5-87ba2cd90dbf@github.com>
Message-ID: <QPBKk8bU6XS75dxWirXO2lAv7EWkNF4uN8PzTz1EuiI=.667fc50d-dd4c-4af6-ba53-4559a0d6f8ee@github.com>

On Wed, 9 Sep 2020 13:11:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed JVMFlag::is_writeable()
>
> src/hotspot/share/runtime/flags/jvmFlag.cpp line 266:
> 
>> 264:
>> 265: bool JVMFlag::is_writeable() const {
>> 266:   return is_manageable();
> 
> Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags
> writeable in non-product builds?

All flags shouldn't be also writeable.  Interpreter code generation depends on static value of some flags, for instance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From coleenp at openjdk.java.net  Wed Sep  9 14:20:02 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 9 Sep 2020 14:20:02 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
Message-ID: <qhW8toJLVceFF0h4ejLsTP8Kc02XuefpFXOU8UOEZI0=.5ae5dd12-36ea-434f-bb91-6a2795cd7d13@github.com>

On Wed, 9 Sep 2020 14:16:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed JVMFlag::is_writeable()
>
> Marked as reviewed by coleenp (Reviewer).

Looks good.  I had a couple of minor comments.
> In JDK-8081833, I plan to use templates to replaces the nearly identical code in
> jvmFlagRangeList.cpp/jvmFlagConstraintList.cpp, and these macros should go away.
Good!

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 15:41:40 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 15:41:40 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <QPBKk8bU6XS75dxWirXO2lAv7EWkNF4uN8PzTz1EuiI=.667fc50d-dd4c-4af6-ba53-4559a0d6f8ee@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <LsmLtYObTVpq4R5gBHeAUb1zP_EDOluIZeFxUY0R9A8=.9f67ecbe-65cd-45c8-b4d5-87ba2cd90dbf@github.com>
 <QPBKk8bU6XS75dxWirXO2lAv7EWkNF4uN8PzTz1EuiI=.667fc50d-dd4c-4af6-ba53-4559a0d6f8ee@github.com>
Message-ID: <Y3tlv_EOAi7oAid_0_Nq-dar7rLFDsBeayLgDeOZqUI=.2960e1c0-c593-4f8d-aa7a-22064a4c95e5@github.com>

On Wed, 9 Sep 2020 14:06:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/flags/jvmFlag.cpp line 266:
>> 
>>> 264:
>>> 265: bool JVMFlag::is_writeable() const {
>>> 266:   return is_manageable();
>> 
>> Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags
>> writeable in non-product builds?
>
> All flags shouldn't be also writeable.  Interpreter code generation depends on static value of some flags, for instance.

is_writeable() doesn't mean "modifiable". The meaning is

// manageable flags are writeable external product flags.
//    They are dynamically writeable through the JDK management interface
//    (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole.

See also
[writeableFlags.cpp](https://github.com/openjdk/jdk/blob/433394203dce55db95caefcb57bac9ec114ebc47/src/hotspot/share/services/writeableFlags.cpp#L283).

There used to be `product_rw` flags, which were "writeable" but not "manageable". However, there aren't any of them
anymore. So I have deleted product_rw() from the comments.

/**** removed comments ****/
// product_rw flags are writeable internal product flags.
//    They are like "manageable" flags but for internal/private use.
//    The list of product_rw flags are internal/private flags which
//    may be changed/removed in a future release.  It can be set
//    through the management interface to get/set value
//    when the name of flag is supplied.
//
//    A flag can be made as "product_rw" only if
//    - the VM implementation supports dynamic setting of the flag.
//      This implies that the VM must *always* query the flag variable
//      and not reuse state related to the flag state at any given time.
//
// Note that when there is a need to support develop flags to be writeable,
// it can be done in the same way as product_rw.

I also removed the implementation of product_rw(). Line 269 is part of the product_rw() removal.

I considered adding support for product_rw() in the new flags implementation. It would be fairly trivial (similar to
how MANAGEABLE is supported) but I am hesitant to do it because:

- No one uses it currently
- There are no test cases

I don't want to have an untested implementation which someone might accidently use in the future without any testing.
If anyone indeed finds producy_rw useful, they can easily implement the functionality and can write tests for it at the
same time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 19:41:05 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 19:41:05 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
Message-ID: <wUCMPZXXkkGiRFNjrrRufmya5UPJhVp-mp65r_Fb_jc=.f832231e-bc55-43db-8382-0e8d9e14f036@github.com>

On Wed, 9 Sep 2020 14:09:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed JVMFlag::is_writeable()
>
> src/hotspot/share/runtime/flags/jvmFlag.hpp line 36:
> 
>> 34: typedef const char* (*RangeStrFunc)(void);
>> 35:
>> 36: struct JVMFlag {
> 
> I'm still getting used to git diffs, but can you change this from struct to class?  Because it looks like it does have
> private and public sections.

I want to limit the changes in this PR, so I plan to do this in a future RFE, probably
[JDK-8081833](https://bugs.openjdk.java.net/browse/JDK-8081833). I'll also change all the fields to private, and add
accessor methods to them. And also add proper iterators for the flags (instead of walking JVMFlag::flags[] directly).

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From coleenp at openjdk.java.net  Wed Sep  9 19:56:20 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 9 Sep 2020 19:56:20 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <wUCMPZXXkkGiRFNjrrRufmya5UPJhVp-mp65r_Fb_jc=.f832231e-bc55-43db-8382-0e8d9e14f036@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
 <wUCMPZXXkkGiRFNjrrRufmya5UPJhVp-mp65r_Fb_jc=.f832231e-bc55-43db-8382-0e8d9e14f036@github.com>
Message-ID: <LSlic952ClpANqdbeYJjd7J3tA5IOoYM5XOHKR6dbN4=.224c6ab7-721d-4b2e-96dc-fdad64526cd7@github.com>

On Wed, 9 Sep 2020 19:38:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/runtime/flags/jvmFlag.hpp line 36:
>> 
>>> 34: typedef const char* (*RangeStrFunc)(void);
>>> 35:
>>> 36: struct JVMFlag {
>> 
>> I'm still getting used to git diffs, but can you change this from struct to class?  Because it looks like it does have
>> private and public sections.
>
> I want to limit the changes in this PR, so I plan to do this in a future RFE, probably
> [JDK-8081833](https://bugs.openjdk.java.net/browse/JDK-8081833). I'll also change all the fields to private, and add
> accessor methods to them. And also add proper iterators for the flags (instead of walking JVMFlag::flags[] directly).

Ok that would be fine as a further change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 20:47:33 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 20:47:33 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
Message-ID: <DtEgghaGapQ_prY5qwL34ssewGmrldIwH7m8erirH-c=.d5693a47-f03a-4bf5-ac76-079890670bf2@github.com>

On Wed, 9 Sep 2020 14:13:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed JVMFlag::is_writeable()
>
> src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 44:
> 
>> 42:     }
>> 43:     return h;
>> 44:   }
> 
> Can this function just call hash_code(s, strlen(s)) ?

strlen() is not constexpr so it can't be used here. I added my hand-rolled string_len function in
[bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b) so we can share a
single copy of the hash calculation loop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 20:47:32 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 20:47:32 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v4]
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <XYoSnbRjlGK9GIABD3lFn6pq0000cn0A33Kn_E2gyZ0=.bd76738e-c63e-4aba-901f-fd67c7babcfa@github.com>

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/82/files
  - new: https://git.openjdk.java.net/jdk/pull/82/files/10246284..bf90a376

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=02-03

  Stats: 24 lines in 2 files changed: 7 ins; 12 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 20:53:13 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 20:53:13 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
Message-ID: <xkPv6-XIesuZmHcMHd4vVctxPPKQnDGwJIPLw_rcBFc=.188b69ef-361b-43ca-8e0c-2cf27db60e7a@github.com>

On Wed, 9 Sep 2020 14:12:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed JVMFlag::is_writeable()
>
> src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 102:
> 
>> 100:   static constexpr const JVMFlagLimit* get_limit(const JVMTypedFlagLimit<T>* p, int dummy, ConstraintMarker
>> dummy2, short func, int phase, T min, T max) { 101:     return p;
>> 102:   }
> 
> Instead of the 'no_limit' functions, could you have get_limit have PRODUCT_RETURN(NULL) ?  Otherwise, fine to get the
> macros working.

I think your suggestion would simply the macro materialization from
#ifdef PRODUCT
  ALL_FLAGS(FLAG_LIMIT_PTR_NONE,
            FLAG_LIMIT_PTR_NONE,
            FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR_NONE,
            APPLY_FLAG_RANGE,
            APPLY_FLAG_CONSTRAINT)
#else
  ALL_FLAGS(FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR,
            APPLY_FLAG_RANGE,
            APPLY_FLAG_CONSTRAINT)
#endif
to
ALL_FLAGS(FLAG_LIMIT_PTR_NOT_PRODUCT,
            FLAG_LIMIT_PTR_NOT_PRODUCT,
            FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR,
            FLAG_LIMIT_PTR_NOT_PRODUCT,
            APPLY_FLAG_RANGE,
            APPLY_FLAG_CONSTRAINT)
But I would need twice the number of the get_limit functions, like:
  static constexpr const JVMFlagLimit* get_limit(const JVMTypedFlagLimit<T>* p, int dummy, T min, T max) {
    return p;    // return product flag for all builds
  }
  static constexpr const JVMFlagLimit* get_limit_not_product(const JVMTypedFlagLimit<T>* p, int dummy, T min, T max) {
    NOT_PRODUCT(return p);     // return non-product flag only in non-product builds
    PRODUCT_ONLY(return NULL);  // .... but not in product build
  }
So the code will be more verbose than before.

Instead, in [bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b), I
changed no_limit to a varargs function so now there's only one version of it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From coleenp at openjdk.java.net  Wed Sep  9 21:09:28 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 9 Sep 2020 21:09:28 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v4]
In-Reply-To: <XYoSnbRjlGK9GIABD3lFn6pq0000cn0A33Kn_E2gyZ0=.bd76738e-c63e-4aba-901f-fd67c7babcfa@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <XYoSnbRjlGK9GIABD3lFn6pq0000cn0A33Kn_E2gyZ0=.bd76738e-c63e-4aba-901f-fd67c7babcfa@github.com>
Message-ID: <IFX09jJtvvTLDmecSXobEOzBmzGWLim5JIy8TZoQeF4=.d8a6eef4-bf03-4a5c-8133-2a63bd81f0a9@github.com>

On Wed, 9 Sep 2020 20:47:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
>> same patch as
>> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
>> published in
>> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
>> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()

Marked as reviewed by coleenp (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From coleenp at openjdk.java.net  Wed Sep  9 21:09:28 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 9 Sep 2020 21:09:28 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <DtEgghaGapQ_prY5qwL34ssewGmrldIwH7m8erirH-c=.d5693a47-f03a-4bf5-ac76-079890670bf2@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
 <DtEgghaGapQ_prY5qwL34ssewGmrldIwH7m8erirH-c=.d5693a47-f03a-4bf5-ac76-079890670bf2@github.com>
Message-ID: <Pupq6e3Y0jcyzpPC0p9oU2R3e3Q_YNMCLESSKJtJ-h4=.0bff7f0d-5b56-4bf8-b353-60e51cb370aa@github.com>

On Wed, 9 Sep 2020 20:44:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 44:
>> 
>>> 42:     }
>>> 43:     return h;
>>> 44:   }
>> 
>> Can this function just call hash_code(s, strlen(s)) ?
>
> strlen() is not constexpr so it can't be used here. I added my hand-rolled string_len function in
> [bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b) so we can share a
> single copy of the hash calculation loop.

Nice!

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 21:23:32 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 21:23:32 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v5]
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <EvkXPJ35NIqE0R6u_-KS2eyqbRGTRu6BaNkXU53xKS0=.2d49ab77-bd65-4338-b1e4-5e9c32bf5355@github.com>

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Feedback by Gerard (hotspot-dev/2020-September/043019.html)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/82/files
  - new: https://git.openjdk.java.net/jdk/pull/82/files/bf90a376..15547ebe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=03-04

  Stats: 23 lines in 6 files changed: 8 ins; 3 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Wed Sep  9 21:36:49 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 9 Sep 2020 21:36:49 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v4]
In-Reply-To: <IFX09jJtvvTLDmecSXobEOzBmzGWLim5JIy8TZoQeF4=.d8a6eef4-bf03-4a5c-8133-2a63bd81f0a9@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <XYoSnbRjlGK9GIABD3lFn6pq0000cn0A33Kn_E2gyZ0=.bd76738e-c63e-4aba-901f-fd67c7babcfa@github.com>
 <IFX09jJtvvTLDmecSXobEOzBmzGWLim5JIy8TZoQeF4=.d8a6eef4-bf03-4a5c-8133-2a63bd81f0a9@github.com>
Message-ID: <PZ31hzG3VaJqCG4QnQBGS1Wh8B4AgBPSkV3l016yPBg=.f3e1e791-b133-41fd-b001-34f8d02384bf@github.com>

On Wed, 9 Sep 2020 21:06:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()
>
> Marked as reviewed by coleenp (Reviewer).

Re: [Gerard Ziemski's comments on
hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043019.html):

I made the changes in [15547eb](https://github.com/openjdk/jdk/pull/82/commits/15547ebe703fcc3a4ce154f2a01f45b756051c26)

Gerard #6 Do we need to provide base of the enums
(https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/hotspot-style.html#enum)
in files:

a) open/src/hotspot/share/runtime/globals_extension.hpp
   43 typedef enum {
   44   ALL_FLAGS(FLAG_MEMBER_ENUM_DEVELOP,
   45             FLAG_MEMBER_ENUM_PD_DEVELOP,
   46             FLAG_MEMBER_ENUM_PRODUCT,
   47             FLAG_MEMBER_ENUM_PD_PRODUCT,
   48             FLAG_MEMBER_ENUM_NOTPRODUCT,
   49             IGNORE_RANGE,
   50             IGNORE_CONSTRAINT)
   51   NUM_JVMFlagsEnum
   52 } JVMFlagsEnum;

b) src/hotspot/share/runtime/flags/jvmFlagLimit.cpp
   46 enum JVMFlagConstraintsEnum {
   47   ALL_CONSTRAINTS(CONSTRAINT_ENUM_)
   48   NUM_JVMFlagConstraintsEnum
   49 };

I added `enum ... : int` as the base.

Gerard #7 Should these enums be replaced with ordinary constants
(https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/hotspot-style.html#enum)
in files:

a) open/src/hotspot/share/runtime/flags/jvmFlagLimit.hpp
   44 class JVMFlagLimit {
   45   enum {
   46     HAS_RANGE = 1,
   47     HAS_CONSTRAINT = 2
   48   };
 

Changed to static constexpr int HAS_RANGE = 1, etc.

Gerard #8 Can we add a description to
"src/hotspot/share/runtime/flags/jvmFlagLookup.hpp? on how ?constexpr"
makes this hash table possible at the compile time?

I added
// This is a hashtable that maps from (const char*) to (JVMFlag*) to speed up
// the processing of JVM command-line argument at runtime.
//
// With constexpr, this table is generated at C++ compile time so there's
// no set up cost at runtime.
class JVMFlagLookup { ...

Gerard #9 Shouldn?t the code in JVMFlagLookup::JVMFlagLookup() initializing the
internal tables be more like:

constexpr JVMFlagLookup::JVMFlagLookup() : _buckets(), _table(), _hashes() {
   for (int i = 0; i < NUM_BUCKETS; i++) {
     _buckets[i] = -1;
   }
   for (int i = 0; i < NUM_JVMFlagsEnum; i++) {
     _hashes[i] = 0;
     _table[i] = -1;
   }
There's no need to initialize _hashes and _table in a loop. Each of the elements in these two arrays are individually
initialized by the expansion of this macro: #define DO_HASH(flag_enum, flag_name) {          \
  unsigned int hash = hash_code(flag_name);      \
  int bucket_index = (int)(hash % NUM_BUCKETS);  \
  _hashes[flag_enum] = (u2)(hash);               \
  _table[flag_enum] = _buckets[bucket_index];    \
  _buckets[bucket_index] = (short)flag_enum;     \
}
...
  ALL_FLAGS(DO_FLAG,
            DO_FLAG,
            DO_FLAG,
            DO_FLAG,
            DO_FLAG,
            IGNORE_RANGE,
            IGNORE_CONSTRAINT)
There was a bug in my previous version that unnecessarily initialized ` _hashes[i] = 0` in the loop. I've removed it.

Gerard #10 ?flagTable_verify_constexpr" and ?flagTable?, in
"src/hotspot/share/runtime/flags/jvmFlag.cpp?, are almost identical -
can we find a way to create just one table (of the ?constexpr? type)?

flagTable_verify_constexpr[] is needed for build-time checking only, and cannot be combined with flagTable[]. I've
updated the comments to clarify:

// We want flagTable[] to be completely initialized at C++ compilation time, which requires
// that all arguments passed to JVMFlag() constructors to be constexpr. The following line
// checks for this this -- if any non-constexpr arguments are passed, the C++ compiler will
// generate an error.
//
// constexpr implies internal linkage. This means the flagTable_verify_constexpr[] variable
// will not be included in jvmFlag.o, so there's no footprint cost for having this variable.
//
// Note that we cannot declare flagTable[] as constexpr because JVMFlag::_flags is modified
// at runtime.
constexpr JVMFlag flagTable_verify_constexpr[] = { MATERIALIZE_ALL_FLAGS };

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From dcubed at openjdk.java.net  Wed Sep  9 23:26:50 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 9 Sep 2020 23:26:50 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v7]
In-Reply-To: <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>
 <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com>
Message-ID: <OpeBn9HRjwkN-pcaq6EDxa4R4riXB86_2FaKAOT-U14=.0e10c71b-6ade-442f-abcd-221634de69d3@github.com>

On Wed, 9 Sep 2020 14:06:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverted to the original code as the explicit assertion is preferred.
>
> Marked as reviewed by kbarrett (Reviewer).

This is a really nice set of cleanup changes.

I have a few comments.

https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-33
  51   if (thread->is_Java_thread())
  52     return thread->as_Java_thread()->thread_state() == _thread_in_vm;
  53   else
  54     return thread->is_VM_thread();
      nit - this code needs braces. Not your bug, but since you've touched this
      code, do you mind fixing it?

Note: I included the link the webrev had me on, but I have no idea what
file that is...

https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-80

276   guarantee(current == get_thread() || current == get_thread()->active_handshaker(),
277                     "must be current thread or direct handshake");

    nit - the indent on L277 looks wrong in the webrev, but it looks right in
    this paste. I don't know which is telling the truth.

https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-101

 358     this->as_Java_thread()->set_stack_overflow_limit();
 359     this->as_Java_thread()->set_reserved_stack_activation(stack_base());
    nit - do you really need 'this->' here?

https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-107

old code:
2074   if (thread_id == 0) {
2075     // current thread
2076     if (THREAD->is_Java_thread()) {
2077       return ((JavaThread*)THREAD)->cooked_allocated_bytes();
2078     }
2079     return -1;

new code:
2074   if (thread_id == 0) { // current thread
2075     return thread->cooked_allocated_bytes();

If the calling thread is not a JavaThread and passes a thread_id ==0,
I don't think the returns are equivalent.

The craziness in the JavaThread::pd_get_top_frame() functions made my head hurt.
Thanks for cleaning that up!

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From dcubed at openjdk.java.net  Wed Sep  9 23:30:54 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 9 Sep 2020 23:30:54 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v7]
In-Reply-To: <OpeBn9HRjwkN-pcaq6EDxa4R4riXB86_2FaKAOT-U14=.0e10c71b-6ade-442f-abcd-221634de69d3@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>
 <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com>
 <OpeBn9HRjwkN-pcaq6EDxa4R4riXB86_2FaKAOT-U14=.0e10c71b-6ade-442f-abcd-221634de69d3@github.com>
Message-ID: <px7LEkwiCxb4Xmk2H8dzhdYBXnPELOu4Oi3167YUR8k=.d889fa80-d44b-4806-9d62-e69ba782145a@github.com>

On Wed, 9 Sep 2020 23:24:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Marked as reviewed by kbarrett (Reviewer).
>
> This is a really nice set of cleanup changes.
> 
> I have a few comments.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-33
>   51   if (thread->is_Java_thread())
>   52     return thread->as_Java_thread()->thread_state() == _thread_in_vm;
>   53   else
>   54     return thread->is_VM_thread();
>       nit - this code needs braces. Not your bug, but since you've touched this
>       code, do you mind fixing it?
> 
> Note: I included the link the webrev had me on, but I have no idea what
> file that is...
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-80
> 
> 276   guarantee(current == get_thread() || current == get_thread()->active_handshaker(),
> 277                     "must be current thread or direct handshake");
> 
>     nit - the indent on L277 looks wrong in the webrev, but it looks right in
>     this paste. I don't know which is telling the truth.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-101
> 
>  358     this->as_Java_thread()->set_stack_overflow_limit();
>  359     this->as_Java_thread()->set_reserved_stack_activation(stack_base());
>     nit - do you really need 'this->' here?
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-107
> 
> old code:
> 2074   if (thread_id == 0) {
> 2075     // current thread
> 2076     if (THREAD->is_Java_thread()) {
> 2077       return ((JavaThread*)THREAD)->cooked_allocated_bytes();
> 2078     }
> 2079     return -1;
> 
> new code:
> 2074   if (thread_id == 0) { // current thread
> 2075     return thread->cooked_allocated_bytes();
> 
> If the calling thread is not a JavaThread and passes a thread_id ==0,
> I don't think the returns are equivalent.
> 
> The craziness in the JavaThread::pd_get_top_frame() functions made my head hurt.
> Thanks for cleaning that up!

I don't see how to add myself as a reviewer... what am I missing?

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From dcubed at openjdk.java.net  Wed Sep  9 23:42:59 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 9 Sep 2020 23:42:59 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v7]
In-Reply-To: <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>
Message-ID: <HP9VxkS-KvL4ymQwyoQ2bbVohNXWBRjSzPeoTQCSLdA=.ed59871e-f71c-49c6-9ad0-850cf22a0212@github.com>

On Wed, 9 Sep 2020 12:48:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a rather large but generally simple cleanup.
>> 
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>   assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>> 
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted to the original code as the explicit assertion is preferred.

Marked as reviewed by dcubed (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From david.holmes at oracle.com  Thu Sep 10 00:51:29 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Sep 2020 10:51:29 +1000
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <Y3tlv_EOAi7oAid_0_Nq-dar7rLFDsBeayLgDeOZqUI=.2960e1c0-c593-4f8d-aa7a-22064a4c95e5@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <LsmLtYObTVpq4R5gBHeAUb1zP_EDOluIZeFxUY0R9A8=.9f67ecbe-65cd-45c8-b4d5-87ba2cd90dbf@github.com>
 <QPBKk8bU6XS75dxWirXO2lAv7EWkNF4uN8PzTz1EuiI=.667fc50d-dd4c-4af6-ba53-4559a0d6f8ee@github.com>
 <Y3tlv_EOAi7oAid_0_Nq-dar7rLFDsBeayLgDeOZqUI=.2960e1c0-c593-4f8d-aa7a-22064a4c95e5@github.com>
Message-ID: <18822b11-cc68-7c20-3f9f-c7885c1156ac@oracle.com>

Hi Ioi,

On 10/09/2020 1:41 am, Ioi Lam wrote:
> On Wed, 9 Sep 2020 14:06:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> src/hotspot/share/runtime/flags/jvmFlag.cpp line 266:
>>>
>>>> 264:
>>>> 265: bool JVMFlag::is_writeable() const {
>>>> 266:   return is_manageable();
>>>
>>> Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags
>>> writeable in non-product builds?
>>
>> All flags shouldn't be also writeable.  Interpreter code generation depends on static value of some flags, for instance.
> 
> is_writeable() doesn't mean "modifiable". The meaning is
> 
> // manageable flags are writeable external product flags.
> //    They are dynamically writeable through the JDK management interface
> //    (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole.
> 
> See also
> [writeableFlags.cpp](https://github.com/openjdk/jdk/blob/433394203dce55db95caefcb57bac9ec114ebc47/src/hotspot/share/services/writeableFlags.cpp#L283).
> 
> There used to be `product_rw` flags, which were "writeable" but not "manageable". However, there aren't any of them
> anymore. So I have deleted product_rw() from the comments.
> /**** removed comments ****/
> // product_rw flags are writeable internal product flags.
> //    They are like "manageable" flags but for internal/private use.
> //    The list of product_rw flags are internal/private flags which
> //    may be changed/removed in a future release.  It can be set
> //    through the management interface to get/set value
> //    when the name of flag is supplied.
> //
> //    A flag can be made as "product_rw" only if
> //    - the VM implementation supports dynamic setting of the flag.
> //      This implies that the VM must *always* query the flag variable
> //      and not reuse state related to the flag state at any given time.
> //
> // Note that when there is a need to support develop flags to be writeable,
> // it can be done in the same way as product_rw.
> 
> I also removed the implementation of product_rw(). Line 269 is part of the product_rw() removal.
> 
> I considered adding support for product_rw() in the new flags implementation. It would be fairly trivial (similar to
> how MANAGEABLE is supported) but I am hesitant to do it because:
> 
> - No one uses it currently
> - There are no test cases
> 
> I don't want to have an untested implementation which someone might accidently use in the future without any testing.
> If anyone indeed finds producy_rw useful, they can easily implement the functionality and can write tests for it at the
> same time.

Yes sorry for the noise. Obviously most flags are not writeable - their 
value has to be fixed at startup. Doh! I was confused by your earlier 
webrev which showed "|| is_product()" and which seemed "obviously" 
correct. :)

I'm somewhat surprised that none of our product or develop flags are 
writeable any more. It used to be some Print/Trace flags that were 
writeable and they have been replaced by UL. I can imagine wanting to 
dynamically enable/disable diagnostic flags though ...

I wonder if "writeable" should be an attribute like 
diagnostic/experimental, so that manageable flags are just writeable 
product flags? That would be a future RFE of course (if appropriate).

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/82
> 

From dholmes at openjdk.java.net  Thu Sep 10 01:04:17 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Sep 2020 01:04:17 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v5]
In-Reply-To: <EvkXPJ35NIqE0R6u_-KS2eyqbRGTRu6BaNkXU53xKS0=.2d49ab77-bd65-4338-b1e4-5e9c32bf5355@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <EvkXPJ35NIqE0R6u_-KS2eyqbRGTRu6BaNkXU53xKS0=.2d49ab77-bd65-4338-b1e4-5e9c32bf5355@github.com>
Message-ID: <X_jtsP8O8P-JRX2mzSfTnNA0XTAVgtF2X49nqOew5SY=.555a57f6-8c44-4144-bed4-fef6f302da3f@github.com>

On Wed, 9 Sep 2020 21:23:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
>> same patch as
>> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
>> published in
>> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
>> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback by Gerard (hotspot-dev/2020-September/043019.html)

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/runtime/flags/jvmFlag.cpp line 714:

> 712:
> 713: // We want flagTable[] to be completely initialized at C++ compilation time, which requires
> 714: // that all arguments passed to JVMFlag() constructors to be constexpr. The following line

line 714: s/to be/be/

src/hotspot/share/runtime/flags/jvmFlag.cpp line 715:

> 713: // We want flagTable[] to be completely initialized at C++ compilation time, which requires
> 714: // that all arguments passed to JVMFlag() constructors to be constexpr. The following line
> 715: // checks for this this -- if any non-constexpr arguments are passed, the C++ compiler will

typo: this this

src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 32:

> 30:
> 31: // This is a hashtable that maps from (const char*) to (JVMFlag*) to speed up
> 32: // the processing of JVM command-line argument at runtime.

s/argument/arguments/

src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 46:

> 44:     size_t len = 0;
> 45:     while (*s != 0) {
> 46:       len ++;

Unwanted space before ++

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From david.holmes at oracle.com  Thu Sep 10 03:11:32 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Sep 2020 13:11:32 +1000
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v7]
In-Reply-To: <OpeBn9HRjwkN-pcaq6EDxa4R4riXB86_2FaKAOT-U14=.0e10c71b-6ade-442f-abcd-221634de69d3@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <e7C5UWmKL8kBSfMw2ECnApiWTFrjYd2ePhaJrO0DB6c=.965e32db-012a-4f17-bf50-0b373d78b76a@github.com>
 <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com>
 <OpeBn9HRjwkN-pcaq6EDxa4R4riXB86_2FaKAOT-U14=.0e10c71b-6ade-442f-abcd-221634de69d3@github.com>
Message-ID: <c83f0e8f-274c-96ce-d425-fe65c5597d0c@oracle.com>

Hi Dan,

Thanks for looking at this one.

On 10/09/2020 9:26 am, Daniel D.Daugherty wrote:
> On Wed, 9 Sep 2020 14:06:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> 
>>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Reverted to the original code as the explicit assertion is preferred.
>>
>> Marked as reviewed by kbarrett (Reviewer).
> 
> This is a really nice set of cleanup changes.
> 
> I have a few comments.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-33
>    51   if (thread->is_Java_thread())
>    52     return thread->as_Java_thread()->thread_state() == _thread_in_vm;
>    53   else
>    54     return thread->is_VM_thread();
>        nit - this code needs braces. Not your bug, but since you've touched this
>        code, do you mind fixing it?

Yes will add braces.

So glad you picked on this though as I messed up one of my commits and 
rolled back to the v1 version, forgetting that it was broken in v1. The 
original line is:

     return true;  //something like this: thread->is_VM_thread();

so I tried:

     return thread->is_VM_thread();

but it causes the assertion to fail as GC threads also execute this. So 
I've restored to the original "return true;" but updated the comment.

> Note: I included the link the webrev had me on, but I have no idea what
> file that is...

Yeah those links are pretty obscure, and even the webrev frames view it 
takes you to doesn't give the name of the file. :(

> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-80
> 
> 276   guarantee(current == get_thread() || current == get_thread()->active_handshaker(),
> 277                     "must be current thread or direct handshake");
> 
>      nit - the indent on L277 looks wrong in the webrev, but it looks right in
>      this paste. I don't know which is telling the truth.

It was wrong - fixed.

> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-101
> 
>   358     this->as_Java_thread()->set_stack_overflow_limit();
>   359     this->as_Java_thread()->set_reserved_stack_activation(stack_base());
>      nit - do you really need 'this->' here?

Nope. Fixed.

> https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-107
> 
> old code:
> 2074   if (thread_id == 0) {
> 2075     // current thread
> 2076     if (THREAD->is_Java_thread()) {
> 2077       return ((JavaThread*)THREAD)->cooked_allocated_bytes();
> 2078     }
> 2079     return -1;
> 
> new code:
> 2074   if (thread_id == 0) { // current thread
> 2075     return thread->cooked_allocated_bytes();
> 
> If the calling thread is not a JavaThread and passes a thread_id ==0,
> I don't think the returns are equivalent.

This code is in a JVM_ENTRY - so both THREAD and thread refer to 
JavaThread::current(), so we can never hit the "return -1;".

> The craziness in the JavaThread::pd_get_top_frame() functions made my head hurt.
> Thanks for cleaning that up!

Thanks again for the review. v8 will be appearing shortly.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/37
> 

From dholmes at openjdk.java.net  Thu Sep 10 03:18:23 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Sep 2020 03:18:23 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v8]
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <u79HLWr6vV7OmyDyVK05fiHbPDbsCwAQQvSlJj7tnD0=.88468c19-a3ae-4174-8444-39d5d2a86b37@github.com>

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed serious bug in dependencies.cpp. The v1 change was wrong and got restored but
  not commited, then a later rollback to v1 lost the fix.
  
  Minor issues Dan spotted now fixed.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/37/files
  - new: https://git.openjdk.java.net/jdk/pull/37/files/50575621..f3d26024

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=06-07

  Stats: 7 lines in 3 files changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk/pull/37

From iklam at openjdk.java.net  Thu Sep 10 04:36:51 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 10 Sep 2020 04:36:51 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v6]
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com>

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last
revision:

 - Merge branch 'master' into 8243208-cleanup-jvmflag-impl
 - Minor code clean up suggested by David Holmes
 - Feedback by Gerard (hotspot-dev/2020-September/043019.html)
 - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()
 - Fixed JVMFlag::is_writeable()
 - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(),
   (d) removed product_rw which is not used by any flags
 - 8243208: Clean up JVMFlag implementation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/82/files
  - new: https://git.openjdk.java.net/jdk/pull/82/files/15547ebe..1b63ac6f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=04-05

  Stats: 452 lines in 56 files changed: 165 ins; 165 del; 122 mod
  Patch: https://git.openjdk.java.net/jdk/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk/pull/82

From kbarrett at openjdk.java.net  Thu Sep 10 06:19:13 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 10 Sep 2020 06:19:13 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v8]
In-Reply-To: <u79HLWr6vV7OmyDyVK05fiHbPDbsCwAQQvSlJj7tnD0=.88468c19-a3ae-4174-8444-39d5d2a86b37@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <u79HLWr6vV7OmyDyVK05fiHbPDbsCwAQQvSlJj7tnD0=.88468c19-a3ae-4174-8444-39d5d2a86b37@github.com>
Message-ID: <XH7j7l5LZZH2xYuDCqP_B9Cvunlnw5b1-EWdhyEzPXg=.769eeedf-2033-40ea-8775-8902d3d8a48b@github.com>

On Thu, 10 Sep 2020 03:18:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a rather large but generally simple cleanup.
>> 
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>   assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>> 
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed serious bug in dependencies.cpp. The v1 change was wrong and got restored but
>   not commited, then a later rollback to v1 lost the fix.
>   
>   Minor issues Dan spotted now fixed.

Marked as reviewed by kbarrett (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From dholmes at openjdk.java.net  Thu Sep 10 07:40:40 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Sep 2020 07:40:40 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v6]
In-Reply-To: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com>
Message-ID: <QZFoxnFtZWrin0UYEmmd5Y7Huqoty22MOKQc8I01MTg=.1be923f3-b5a2-4573-ab1e-aba956f93a8b@github.com>

On Thu, 10 Sep 2020 04:36:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
>> same patch as
>> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
>> published in
>> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
>> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
> the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last
> revision:
>  - Merge branch 'master' into 8243208-cleanup-jvmflag-impl
>  - Minor code clean up suggested by David Holmes
>  - Feedback by Gerard (hotspot-dev/2020-September/043019.html)
>  - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()
>  - Fixed JVMFlag::is_writeable()
>  - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(),
>    (d) removed product_rw which is not used by any flags
>  - 8243208: Clean up JVMFlag implementation

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From dcubed at openjdk.java.net  Thu Sep 10 14:46:40 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Sep 2020 14:46:40 GMT
Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience
 function [v8]
In-Reply-To: <u79HLWr6vV7OmyDyVK05fiHbPDbsCwAQQvSlJj7tnD0=.88468c19-a3ae-4174-8444-39d5d2a86b37@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
 <u79HLWr6vV7OmyDyVK05fiHbPDbsCwAQQvSlJj7tnD0=.88468c19-a3ae-4174-8444-39d5d2a86b37@github.com>
Message-ID: <Vn4rA9dAwmogdi_wqLeGhgZTfwL1bDwDL2PoQFk97D4=.873217cd-4201-4483-84a0-ee0f9e1685d2@github.com>

On Thu, 10 Sep 2020 03:18:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a rather large but generally simple cleanup.
>> 
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
>> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
>> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
>> - changed raw casts to use as_Java_thread()
>> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
>> - Removed checks that are checking the type system e.g.
>> void foo(JavaThread* t) {
>>   assert(t->is_Java_thread(), "must be")
>> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
>> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
>> assertion is at the head of any such call chain.
>> - Removed asserts that are already guaranteed in the caller.
>> - Use JavaThread::current() where appropriate.
>> - Use pre-existing "thread" variable where available rather than casting THREAD
>> 
>> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
>> been missed.
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed serious bug in dependencies.cpp. The v1 change was wrong and got restored but
>   not commited, then a later rollback to v1 lost the fix.
>   
>   Minor issues Dan spotted now fixed.

Incremental looks good to me.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/37

From gziemski at openjdk.java.net  Thu Sep 10 15:35:12 2020
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 10 Sep 2020 15:35:12 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v6]
In-Reply-To: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com>
Message-ID: <f2t24MvTqsFmQiNpN_f-iT65ed3NS5g8cAvYsX_4t50=.ac881a69-a469-4098-a6f3-290a22738b07@github.com>

On Thu, 10 Sep 2020 04:36:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
>> same patch as
>> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
>> published in
>> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
>> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
> the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last
> revision:
>  - Merge branch 'master' into 8243208-cleanup-jvmflag-impl
>  - Minor code clean up suggested by David Holmes
>  - Feedback by Gerard (hotspot-dev/2020-September/043019.html)
>  - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()
>  - Fixed JVMFlag::is_writeable()
>  - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(),
>    (d) removed product_rw which is not used by any flags
>  - 8243208: Clean up JVMFlag implementation

Marked as reviewed by gziemski (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From gziemski at openjdk.java.net  Thu Sep 10 15:45:26 2020
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 10 Sep 2020 15:45:26 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v3]
In-Reply-To: <Pupq6e3Y0jcyzpPC0p9oU2R3e3Q_YNMCLESSKJtJ-h4=.0bff7f0d-5b56-4bf8-b353-60e51cb370aa@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <iAN1yTF4CS8r1wHRjjjpi4XktH0qtAZby0e5fz4DpJQ=.18e577e1-20b6-4c2a-aba9-c3f163850db4@github.com>
 <cfRxrVUDi8l8CzB-PYdlxO7AZSAqmQzCXFKdw6ZxGK0=.eb865cda-edc3-46ee-980f-ea2ebf98510a@github.com>
 <DtEgghaGapQ_prY5qwL34ssewGmrldIwH7m8erirH-c=.d5693a47-f03a-4bf5-ac76-079890670bf2@github.com>
 <Pupq6e3Y0jcyzpPC0p9oU2R3e3Q_YNMCLESSKJtJ-h4=.0bff7f0d-5b56-4bf8-b353-60e51cb370aa@github.com>
Message-ID: <Ky5y1oLvjnSc1zBCGjf45SC640tVhwWDpA1VH3QTu1M=.87c7dc62-270c-4162-bef7-51534c2db560@github.com>

On Wed, 9 Sep 2020 21:06:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> strlen() is not constexpr so it can't be used here. I added my hand-rolled string_len function in
>> [bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b) so we can share a
>> single copy of the hash calculation loop.
>
> Nice!

I had the same question, cool.

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From dholmes at openjdk.java.net  Fri Sep 11 01:35:12 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Sep 2020 01:35:12 GMT
Subject: Integrated: 8252406: Introduce Thread::as_Java_thread() convenience
 function
In-Reply-To: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
References: <eGtW27XZe9sv7AxaZP8vbl_X0r_Mr_PTeK90-pGAIPc=.1c55b016-5e14-45a0-bfb6-ff5d96f543c1@github.com>
Message-ID: <EiBPTJexPKWR4fR80bUgSfXiFeFJ5iIQgDCtLMumXN8=.6f86f517-e8a7-4a66-b114-87a52ff276e6@github.com>

On Mon, 7 Sep 2020 05:56:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a rather large but generally simple cleanup.
> 
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(),
> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was
> also added to allow use in cases where we start with "const Thread *".  Summary of changes:
> - changed raw casts to use as_Java_thread()
> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread()
> - Removed checks that are checking the type system e.g.
> void foo(JavaThread* t) {
>   assert(t->is_Java_thread(), "must be")
> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry
> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the
> assertion is at the head of any such call chain.
> - Removed asserts that are already guaranteed in the caller.
> - Use JavaThread::current() where appropriate.
> - Use pre-existing "thread" variable where available rather than casting THREAD
> 
> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have
> been missed.
> Testing: tiers 1-3
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 976acdde
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/976acdde
Stats:     476 lines in 110 files changed: 116 ins; 20 del; 340 mod

8252406: Introduce Thread::as_Java_thread() convenience function

Reviewed-by: shade, coleenp, kbarrett, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/37

From iklam at openjdk.java.net  Fri Sep 11 04:01:52 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 11 Sep 2020 04:01:52 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v7]
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <VhZ84hXP5xGMbbujt47Bm_CNaNEo_YoNun0ESCzsJXE=.387f7936-584b-4bc2-8c06-5abc934feea5@github.com>

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last
revision:

 - Merge branch 'master' into 8243208-cleanup-jvmflag-impl
 - Merge branch 'master' into 8243208-cleanup-jvmflag-impl
 - Minor code clean up suggested by David Holmes
 - Feedback by Gerard (hotspot-dev/2020-September/043019.html)
 - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()
 - Fixed JVMFlag::is_writeable()
 - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(),
   (d) removed product_rw which is not used by any flags
 - 8243208: Clean up JVMFlag implementation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/82/files
  - new: https://git.openjdk.java.net/jdk/pull/82/files/1b63ac6f..af373e44

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=05-06

  Stats: 1879 lines in 195 files changed: 584 ins; 641 del; 654 mod
  Patch: https://git.openjdk.java.net/jdk/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82

PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Fri Sep 11 04:08:07 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 11 Sep 2020 04:08:07 GMT
Subject: Integrated: 8243208: Clean up JVMFlag implementation
In-Reply-To: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
Message-ID: <CsaKHt4kDC9cSW6Gb9BOlIIrou8Eb5vXxBr87mJNXZQ=.a1c21d1a-a981-4140-bf69-4a3a179aefec@github.com>

On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the
> same patch as
> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/)
> published in
> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html).  The
> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail.

This pull request has now been integrated.

Changeset: 5144190e
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5144190e
Stats:     2127 lines in 45 files changed: 533 ins; 755 del; 839 mod

8243208: Clean up JVMFlag implementation

Reviewed-by: dholmes, coleenp, gziemski

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From lzang at openjdk.java.net  Fri Sep 11 09:09:25 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 11 Sep 2020 09:09:25 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v2]
In-Reply-To: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
Message-ID: <l-pHdD63w-14ltIVMjkw2WgenpPmTQx56SHCGwnad0g=.839cd888-90bf-4c5b-b436-e0c083b0aba9@github.com>

> - enable parallel heap inspecton for ShenandoahHeap
>   - preliminary evaluation:
>     Time of jmap histo on (8GB heap with 4GB objects)
>     * before: 5.186s
>     * after : 1.698s

Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
will show differences compared to the previous content of the PR. The pull request contains one new commit since the
last revision:

  8252104: parallel heap inspection for ShenandoahHeap
  
    - enable parallel heap inspecton for ShenandoahHeap
    - preliminary evaluation:
      Time of jmap histo on (8GB heap with 4GB objects)
      * before: 5.186s
      * after : 1.698s

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/67/files
  - new: https://git.openjdk.java.net/jdk/pull/67/files/7b400d2c..6645cc27

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=00-01

  Stats: 138 lines in 2 files changed: 56 ins; 71 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/67/head:pull/67

PR: https://git.openjdk.java.net/jdk/pull/67

From lzang at openjdk.java.net  Fri Sep 11 09:09:26 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 11 Sep 2020 09:09:26 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v2]
In-Reply-To: <KybrQhWK_lSIFHMxPpyvr2--klhFMsAebgnsjVnU58I=.2d6e3024-f4ba-4814-b13d-a29226eba551@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>
 <KybrQhWK_lSIFHMxPpyvr2--klhFMsAebgnsjVnU58I=.2d6e3024-f4ba-4814-b13d-a29226eba551@github.com>
Message-ID: <P22B2myTT81fixG8IXWLu-8toxLF41sgfN5MQygJ0FA=.5811a18e-b210-41ca-8694-56601d8ee351@github.com>

On Wed, 9 Sep 2020 03:00:26 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Thanks, this looks interesting.
>> 
>> I need more time to digest this. It feels like we can merge together the parallel (new) and serial (old) heap iteration
>> code for better maintainability. I could try to do so later.
>
> Thanks @shipilev? This is shenandoah support based on parallel heap inspection enabling in serviceability (tracked with
> https://bugs.openjdk.java.net/browse/JDK-8215624). hope it is helpful for your review.

Hi @shipilev,
     I have update a PR that trying to reuse code in serial and parallel heap iteration.
     would you like to review again? Thanks
-Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From shade at openjdk.java.net  Fri Sep 11 10:56:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 11 Sep 2020 10:56:59 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v2]
In-Reply-To: <P22B2myTT81fixG8IXWLu-8toxLF41sgfN5MQygJ0FA=.5811a18e-b210-41ca-8694-56601d8ee351@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>
 <KybrQhWK_lSIFHMxPpyvr2--klhFMsAebgnsjVnU58I=.2d6e3024-f4ba-4814-b13d-a29226eba551@github.com>
 <P22B2myTT81fixG8IXWLu-8toxLF41sgfN5MQygJ0FA=.5811a18e-b210-41ca-8694-56601d8ee351@github.com>
Message-ID: <3Z4xrVeHZ_d5Rcdn41HQUdMm9kdof-CSURtjFYn2lSg=.fa43943f-3175-43ef-8f8e-498ad6fe6512@github.com>

On Fri, 11 Sep 2020 09:05:53 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Thanks @shipilev? This is shenandoah support based on parallel heap inspection enabling in serviceability (tracked with
>> https://bugs.openjdk.java.net/browse/JDK-8215624). hope it is helpful for your review.
>
> Hi @shipilev,
>      I have update a PR that trying to reuse code in serial and parallel heap iteration.
>      would you like to review again? Thanks
> -Lin

Thank you, we'll take a look next week.

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From zgu at openjdk.java.net  Fri Sep 11 13:56:55 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 11 Sep 2020 13:56:55 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v2]
In-Reply-To: <3Z4xrVeHZ_d5Rcdn41HQUdMm9kdof-CSURtjFYn2lSg=.fa43943f-3175-43ef-8f8e-498ad6fe6512@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>
 <KybrQhWK_lSIFHMxPpyvr2--klhFMsAebgnsjVnU58I=.2d6e3024-f4ba-4814-b13d-a29226eba551@github.com>
 <P22B2myTT81fixG8IXWLu-8toxLF41sgfN5MQygJ0FA=.5811a18e-b210-41ca-8694-56601d8ee351@github.com>
 <3Z4xrVeHZ_d5Rcdn41HQUdMm9kdof-CSURtjFYn2lSg=.fa43943f-3175-43ef-8f8e-498ad6fe6512@github.com>
Message-ID: <G7wEqabDpLMebETgcCafU0weoaujEB4VYL9YMp8XNX4=.8814ecf2-f9b3-48fe-97fa-59de5a0a92ba@github.com>

On Fri, 11 Sep 2020 10:54:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi @shipilev,
>>      I have update a PR that trying to reuse code in serial and parallel heap iteration.
>>      would you like to review again? Thanks
>> -Lin
>
> Thank you, we'll take a look next week.

Hi Lin,

1) The patch does not compile with assertion on
@@ -1490,7 +1490,7 @@ private:
       cl->do_object(obj);
       obj->oop_iterate(&oops);
     }
-    assert(q.is_empty(), "should be empty");
+    assert(q->is_empty(), "should be empty");

2) I don't like to export following methods as public. Instead, you can declare ShenandoahParallelObjectIterator as
friend class of ShenandoahHeap.
   void scan_roots_for_iteration(Stack<oop, mtGC>* oop_stack, ObjectIterateScanRootClosure* oops);
   bool prepare_aux_bitmap_for_iteration();
   void reclaim_aux_bitmap_for_iteration();

3) Please rename ObjectIterateParScanClosure to ShenandoahObjectIterateParScanClosure for code convention

4) There is no point to seed mark roots if prepare_aux_bitmap_for_iteration() failed in
ShenandoahParallelObjectIterator constructor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From dcubed at openjdk.java.net  Fri Sep 11 18:55:50 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 18:55:50 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
Message-ID: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>

This RFE is to migrate the following field to OopStorage:

class ObjectMonitor {
<snip>
  void* volatile _object; // backward object pointer - strong root

Unlike the previous patches in this series, there are a lot of collateral
changes so this is not a trivial review. Sorry for the tedious parts of
the review. Since Erik and I are both contributors to this patch, we
would like at least 1 GC team reviewer and 1 Runtime team reviewer.

This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
along with JDK-8252980 and JDK-8252981. I also ran it through my
inflation stress kit for 48 hours on my Linux-X64 machine.

-------------

Commit messages:
 - 8247281: migrate ObjectMonitor::_object to OopStorage

Changes: https://git.openjdk.java.net/jdk/pull/135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247281
  Stats: 445 lines in 36 files changed: 108 ins; 234 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/135/head:pull/135

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 18:55:50 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 18:55:50 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <m4HamTm7qFzMIVwRm12TtrcenLGtxn88OQHIcrvNr-s=.287a3474-0166-4c09-a8aa-267d132a5dbb@github.com>

On Fri, 11 Sep 2020 18:45:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

@fisk - Please chime in on this review when you get the chance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 19:05:43 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 19:05:43 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <c4NP7HOcoDekPUA_3uvYbi3r63Mwdp0k1cO_0KQVtpc=.91338c3f-1c6b-4db3-968f-28ecdc40e3bc@github.com>

On Fri, 11 Sep 2020 18:45:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

The vast majority of these changes came from @fisk so I'm actually a
reviewer and stress tester of these changes. Thumbs up!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Fri Sep 11 19:20:56 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 11 Sep 2020 19:20:56 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <06UhnxjoBW9AUQP_YyeBhiFIIOGQCpyT1SE7NWhSqi0=.c266606c-f72f-4496-95e2-424e3de24a6b@github.com>

On Fri, 11 Sep 2020 18:45:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

This looks great Dan. I like your addition of is_chainmarker() - it makes this step a lot better, without having any
special oops that are not oops. Thanks for sorting this out!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 19:29:21 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 19:29:21 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <06UhnxjoBW9AUQP_YyeBhiFIIOGQCpyT1SE7NWhSqi0=.c266606c-f72f-4496-95e2-424e3de24a6b@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <06UhnxjoBW9AUQP_YyeBhiFIIOGQCpyT1SE7NWhSqi0=.c266606c-f72f-4496-95e2-424e3de24a6b@github.com>
Message-ID: <AKHK9Egr2NsS6WMDkK0VtyywMUVdOZ1V7e0mLvvEQ5Q=.8660b2c0-a3e3-4b57-8ed5-54893d5b431b@github.com>

On Fri, 11 Sep 2020 19:18:26 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> This looks great Dan. I like your addition of is_chainmarker() - it makes this step a lot better, without having any
> special oops that are not oops. Thanks for sorting this out!

@fisk - Thanks for the blinding fast review! (Pretty easy when you wrote almost
all of the code).

Re: is_chainmarker()
I figured you would appreciate getting rid of one more "special" oop value!
And its use just fits in with the whole AllocationState model. It also gets
removed quite easily with the part3 patch... Oh yeah, I gotta file a new RFE
for that one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From coleenp at openjdk.java.net  Fri Sep 11 21:03:35 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 11 Sep 2020 21:03:35 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>

On Fri, 11 Sep 2020 18:45:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

Changes requested by coleenp (Reviewer).

src/hotspot/share/prims/jvmtiTagMap.cpp line 3021:

> 3019:
> 3020:   // Inflated monitors
> 3021:   blk.set_kind(JVMTI_HEAP_REFERENCE_MONITOR);

So we don't have to provide the equivalent of JVMTI_HEAP_REFERENCE_MONITOR?

src/hotspot/share/runtime/objectMonitor.cpp line 246:

> 244: // Check that object() and set_object() are called from the right context:
> 245: static void check_object_context() {
> 246:   Thread *self = Thread::current();

Nit * is in the wrong place.

src/hotspot/share/runtime/objectMonitor.cpp line 251:

> 249:   guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
> 250:   if (self->is_Java_thread()) {
> 251:     JavaThread* jt = (JavaThread*)self;

With David's new change this should use as_Java_thread().

src/hotspot/share/runtime/objectMonitor.cpp line 268:

> 266:     return NULL;
> 267:   }
> 268:   return _object.resolve();

Why would _object be NULL?  It should be non-null after creation.  It might point to null but then _object.resolve()
would return NULL.  This NULL check doesn't make sense to me, same with the peek function below.

src/hotspot/share/services/heapDumper.cpp line 1395:

> 1393:   void do_oop(oop* obj_p) {
> 1394:     u4 size = 1 + sizeof(address);
> 1395:     writer()->start_sub_record(HPROF_GC_ROOT_MONITOR_USED, size);

I had a similar question to the jvmtiTagMap question above.  Are there tools that are going to miss seeing this tag in
the heap dump?  I hope these tags are implementation defined and we can just remove them.  Otherwise, should there be a
loop through the OM list to print out these tags for live object monitors?

src/hotspot/share/runtime/synchronizer.cpp line 1548:

> 1546:                                     bool from_per_thread_alloc) {
> 1547:   guarantee(m->header().value() == 0, "invariant");
> 1548:   guarantee(m->object_peek() == NULL, "invariant");

Because of type stable memory, you don't release the WeakHandle when the OM is released.  The oop inside the WeakHandle
is replaced in when an OM is reused?

src/hotspot/share/runtime/synchronizer.cpp line 163:

> 161:
> 162: #define CHAINMARKER (cast_to_oop<intptr_t>(-1))
> 163:

Great. One less non-oop oop!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Fri Sep 11 21:20:21 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 11 Sep 2020 21:20:21 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
Message-ID: <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>

On Fri, 11 Sep 2020 20:31:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 3021:
> 
>> 3019:
>> 3020:   // Inflated monitors
>> 3021:   blk.set_kind(JVMTI_HEAP_REFERENCE_MONITOR);
> 
> So we don't have to provide the equivalent of JVMTI_HEAP_REFERENCE_MONITOR?

The JVMTI roots are strong roots. This is no longer a strong root, so reporting them would be a bug after this change.

> src/hotspot/share/runtime/objectMonitor.cpp line 268:
> 
>> 266:     return NULL;
>> 267:   }
>> 268:   return _object.resolve();
> 
> Why would _object be NULL?  It should be non-null after creation.  It might point to null but then _object.resolve()
> would return NULL.  This NULL check doesn't make sense to me, same with the peek function below.

Because before the TSM removal patch, the monitors are allocated in blocks. Then, the objects are not known when the
monitors are allocated. The handles are instead lazily created... for now. With the next patch, that will probably
change, if we agree to allocate ObjectMonitors one by one on inflation time. But that is one patch away.

> src/hotspot/share/services/heapDumper.cpp line 1395:
> 
>> 1393:   void do_oop(oop* obj_p) {
>> 1394:     u4 size = 1 + sizeof(address);
>> 1395:     writer()->start_sub_record(HPROF_GC_ROOT_MONITOR_USED, size);
> 
> I had a similar question to the jvmtiTagMap question above.  Are there tools that are going to miss seeing this tag in
> the heap dump?  I hope these tags are implementation defined and we can just remove them.  Otherwise, should there be a
> loop through the OM list to print out these tags for live object monitors?

Same answer as above. No longer a strong root, so can't report it as such.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:20:22 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:20:22 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
Message-ID: <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>

On Fri, 11 Sep 2020 21:08:59 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 3021:
>> 
>>> 3019:
>>> 3020:   // Inflated monitors
>>> 3021:   blk.set_kind(JVMTI_HEAP_REFERENCE_MONITOR);
>> 
>> So we don't have to provide the equivalent of JVMTI_HEAP_REFERENCE_MONITOR?
>
> The JVMTI roots are strong roots. This is no longer a strong root, so reporting them would be a bug after this change.

The function is VM_HeapWalkOperation::collect_simple_roots()
and we no longer have a root in the ObjectMonitor so my take is
no we don't. I believe @fisk concurs with that reasoning.

>> src/hotspot/share/runtime/objectMonitor.cpp line 268:
>> 
>>> 266:     return NULL;
>>> 267:   }
>>> 268:   return _object.resolve();
>> 
>> Why would _object be NULL?  It should be non-null after creation.  It might point to null but then _object.resolve()
>> would return NULL.  This NULL check doesn't make sense to me, same with the peek function below.
>
> Because before the TSM removal patch, the monitors are allocated in blocks. Then, the objects are not known when the
> monitors are allocated. The handles are instead lazily created... for now. With the next patch, that will probably
> change, if we agree to allocate ObjectMonitors one by one on inflation time. But that is one patch away.

Erik's part3 patch ensures that when the ObjectMonitor is allocated,
the weak handle is created and initialized to the oop at that point. Since
this is still the TSM version, the ObjectMonitor may not yet have a weak
handle allocated at the time that object() is called.

>> src/hotspot/share/services/heapDumper.cpp line 1395:
>> 
>>> 1393:   void do_oop(oop* obj_p) {
>>> 1394:     u4 size = 1 + sizeof(address);
>>> 1395:     writer()->start_sub_record(HPROF_GC_ROOT_MONITOR_USED, size);
>> 
>> I had a similar question to the jvmtiTagMap question above.  Are there tools that are going to miss seeing this tag in
>> the heap dump?  I hope these tags are implementation defined and we can just remove them.  Otherwise, should there be a
>> loop through the OM list to print out these tags for live object monitors?
>
> Same answer as above. No longer a strong root, so can't report it as such.

We no longer have a root in the ObjectMonitor so no we don't have
to dump these is my take. I believe @fisk concurs with that reasoning.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:20:24 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:20:24 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
Message-ID: <FHiAxagLlXxG33H4tEWkouD8DpWGTh0iYcI2H_KfRLs=.766748e9-9ef2-475b-9faf-63211aeeb6ec@github.com>

On Fri, 11 Sep 2020 20:33:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 246:
> 
>> 244: // Check that object() and set_object() are called from the right context:
>> 245: static void check_object_context() {
>> 246:   Thread *self = Thread::current();
> 
> Nit * is in the wrong place.

I'll fix that.

> src/hotspot/share/runtime/objectMonitor.cpp line 251:
> 
>> 249:   guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
>> 250:   if (self->is_Java_thread()) {
>> 251:     JavaThread* jt = (JavaThread*)self;
> 
> With David's new change this should use as_Java_thread().

Yup. Since this is a new function, it didn't pop up as a conflict.
I'll fix that.

> src/hotspot/share/runtime/synchronizer.cpp line 1548:
> 
>> 1546:                                     bool from_per_thread_alloc) {
>> 1547:   guarantee(m->header().value() == 0, "invariant");
>> 1548:   guarantee(m->object_peek() == NULL, "invariant");
> 
> Because of type stable memory, you don't release the WeakHandle when the OM is released.  The oop inside the WeakHandle
> is replaced in when an OM is reused?

Correct. See:
+void ObjectMonitor::set_object(oop obj) {
+  check_object_context();
+  if (_object.is_null()) {
+    _object = WeakHandle(_oop_storage, obj);
+  } else {
+    _object.replace(obj);
+  }
+}

So when 'obj' == NULL, we replace the weak handle's value with NULL
and we don't release/delete/whatever the weak handle.

> src/hotspot/share/runtime/synchronizer.cpp line 163:
> 
>> 161:
>> 162: #define CHAINMARKER (cast_to_oop<intptr_t>(-1))
>> 163:
> 
> Great. One less non-oop oop!

Exactly!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Fri Sep 11 21:20:24 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 11 Sep 2020 21:20:24 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
Message-ID: <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>

On Fri, 11 Sep 2020 21:09:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The JVMTI roots are strong roots. This is no longer a strong root, so reporting them would be a bug after this change.
>
> The function is VM_HeapWalkOperation::collect_simple_roots()
> and we no longer have a root in the ObjectMonitor so my take is
> no we don't. I believe @fisk concurs with that reasoning.

Yes, exactly.

>> Same answer as above. No longer a strong root, so can't report it as such.
>
> We no longer have a root in the ObjectMonitor so no we don't have
> to dump these is my take. I believe @fisk concurs with that reasoning.

Agreed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From coleenp at openjdk.java.net  Fri Sep 11 21:45:10 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 11 Sep 2020 21:45:10 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
Message-ID: <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>

On Fri, 11 Sep 2020 21:42:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - changes to resolve Coleen's comments.

I approve of this without seeing any new changes.

src/hotspot/share/runtime/thread.cpp line 4593:

> 4591:   // are used in om_flush().
> 4592:   BarrierSet::barrier_set()->on_thread_detach(p);
> 4593:

One last question, that doesn't require a comment why it's here, but why was this moved?

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:45:08 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:45:08 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  coleenp CR - changes to resolve Coleen's comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/135/files
  - new: https://git.openjdk.java.net/jdk/pull/135/files/150a398b..750fe771

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/135/head:pull/135

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:45:10 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:45:10 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <E4KV6VsbUn8kilm-rf6FsfH1jfDdJmL6M4ROVagKl1k=.fa3dad2d-7f9f-462d-9d71-6a75339f0242@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>
 <E4KV6VsbUn8kilm-rf6FsfH1jfDdJmL6M4ROVagKl1k=.fa3dad2d-7f9f-462d-9d71-6a75339f0242@github.com>
Message-ID: <Qp8Db197qhk9A_jxW9VHvBWc1Prcq5aa2MEdNq_jOnM=.77f9309b-322c-4a84-9992-7151d0810b20@github.com>

On Fri, 11 Sep 2020 21:35:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I approve of this without seeing any new changes.
>
> I have to also comment that reviewing code in github is really nice!

Agreed. When I did my self-review for this fix, I didn't use the webrev link at all.
I did generate a local webrev via "git webrev" and sanity checked that webrev
to verify that "git webrev" works (and it did).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From coleenp at openjdk.java.net  Fri Sep 11 21:45:10 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 11 Sep 2020 21:45:10 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>
Message-ID: <E4KV6VsbUn8kilm-rf6FsfH1jfDdJmL6M4ROVagKl1k=.fa3dad2d-7f9f-462d-9d71-6a75339f0242@github.com>

On Fri, 11 Sep 2020 21:33:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - changes to resolve Coleen's comments.
>
> I approve of this without seeing any new changes.

I have to also comment that reviewing code in github is really nice!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From coleenp at openjdk.java.net  Fri Sep 11 21:45:11 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 11 Sep 2020 21:45:11 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
Message-ID: <P0LC2HcvPm40PiEOqOA-n6xmrQ8NRDNPfEyZnvMFJuM=.79b6f441-56e6-4538-b8f8-e8fe137052f7@github.com>

On Fri, 11 Sep 2020 21:13:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Because before the TSM removal patch, the monitors are allocated in blocks. Then, the objects are not known when the
>> monitors are allocated. The handles are instead lazily created... for now. With the next patch, that will probably
>> change, if we agree to allocate ObjectMonitors one by one on inflation time. But that is one patch away.
>
> Erik's part3 patch ensures that when the ObjectMonitor is allocated,
> the weak handle is created and initialized to the oop at that point. Since
> this is still the TSM version, the ObjectMonitor may not yet have a weak
> handle allocated at the time that object() is called.

Ok, this is cool then and good that this logic is here instead of inside the WeakHandle::resolve/peek functions.  The
OopHandle similar functions have a null check, so if this was permanent, I'd suggest putting it there.  Since this is
going to change, having it here and keeping the non-null invariants for WeakHandle::resolve/peek functions is better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From coleenp at openjdk.java.net  Fri Sep 11 21:45:11 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 11 Sep 2020 21:45:11 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
Message-ID: <FUxLEfUVidWZ2-LJlR4GoWIlAV61bDF-pyBSYl8fi98=.5c533df8-e93a-44ef-8620-ed90755b7030@github.com>

On Fri, 11 Sep 2020 21:15:56 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> We no longer have a root in the ObjectMonitor so no we don't have
>> to dump these is my take. I believe @fisk concurs with that reasoning.
>
> Agreed.

Ok, that's good then!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:45:12 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:45:12 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>
Message-ID: <ifMkQC8OKpz5m6Bhx8o3WKKAm-Vaeei21ApmZVdoaw4=.41b2327b-9db1-4a5f-8f69-bba0488f40cc@github.com>

On Fri, 11 Sep 2020 21:33:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - changes to resolve Coleen's comments.
>
> src/hotspot/share/runtime/thread.cpp line 4593:
> 
>> 4591:   // are used in om_flush().
>> 4592:   BarrierSet::barrier_set()->on_thread_detach(p);
>> 4593:
> 
> One last question, that doesn't require a comment why it's here, but why was this moved?

We had to move that code to make om_flush() happy.
om_flush() accesses the (weak) oops in the monitor list
after the thread is off the threads list so the barrier change
had to move. It will move back in part3.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:45:14 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:45:14 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <FHiAxagLlXxG33H4tEWkouD8DpWGTh0iYcI2H_KfRLs=.766748e9-9ef2-475b-9faf-63211aeeb6ec@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <FHiAxagLlXxG33H4tEWkouD8DpWGTh0iYcI2H_KfRLs=.766748e9-9ef2-475b-9faf-63211aeeb6ec@github.com>
Message-ID: <XyDGRQqUQKWYX3uFTXD4MOuaI9dYEXxNJEWfvli3RdE=.39656abc-7af3-4e85-abf1-2b747b70b4ab@github.com>

On Fri, 11 Sep 2020 21:10:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 251:
>> 
>>> 249:   guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
>>> 250:   if (self->is_Java_thread()) {
>>> 251:     JavaThread* jt = (JavaThread*)self;
>> 
>> With David's new change this should use as_Java_thread().
>
> Yup. Since this is a new function, it didn't pop up as a conflict.
> I'll fix that.

Fixed in https://github.com/openjdk/jdk/pull/135/commits/750fe771943178a02f1b71a713f7417512e3628e.

>> src/hotspot/share/runtime/objectMonitor.cpp line 246:
>> 
>>> 244: // Check that object() and set_object() are called from the right context:
>>> 245: static void check_object_context() {
>>> 246:   Thread *self = Thread::current();
>> 
>> Nit * is in the wrong place.
>
> I'll fix that.

Fixed in https://github.com/openjdk/jdk/pull/135/commits/750fe771943178a02f1b71a713f7417512e3628e

>> src/hotspot/share/runtime/synchronizer.cpp line 1548:
>> 
>>> 1546:                                     bool from_per_thread_alloc) {
>>> 1547:   guarantee(m->header().value() == 0, "invariant");
>>> 1548:   guarantee(m->object_peek() == NULL, "invariant");
>> 
>> Because of type stable memory, you don't release the WeakHandle when the OM is released.  The oop inside the WeakHandle
>> is replaced in when an OM is reused?
>
> Correct. See:
> 
> +void ObjectMonitor::set_object(oop obj) {
> +  check_object_context();
> +  if (_object.is_null()) {
> +    _object = WeakHandle(_oop_storage, obj);
> +  } else {
> +    _object.replace(obj);
> +  }
> +}
> 
> So when 'obj' == NULL, we replace the weak handle's value with NULL
> and we don't release/delete/whatever the weak handle.

@fisk  - I can't figure out what "magic" to use to get the above code quote to show up as such. Suggestion?

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:45:12 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:45:12 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
Message-ID: <ExVVaITLKAVIH0GaprYE8g7xQ1GEAjChOAZGTGSO20o=.dc35b788-ffb7-40a6-850c-d80acc61ff9f@github.com>

On Fri, 11 Sep 2020 21:15:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The function is VM_HeapWalkOperation::collect_simple_roots()
>> and we no longer have a root in the ObjectMonitor so my take is
>> no we don't. I believe @fisk concurs with that reasoning.
>
> Yes, exactly.

Thanks for confirmation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:45:14 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:45:14 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <P0LC2HcvPm40PiEOqOA-n6xmrQ8NRDNPfEyZnvMFJuM=.79b6f441-56e6-4538-b8f8-e8fe137052f7@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <P0LC2HcvPm40PiEOqOA-n6xmrQ8NRDNPfEyZnvMFJuM=.79b6f441-56e6-4538-b8f8-e8fe137052f7@github.com>
Message-ID: <F3gAnD62wguhB-a3wA5UKV7BveictfwkwkQQDvhLLd4=.fde09d14-5ba3-4a11-8400-c63de493bd4c@github.com>

On Fri, 11 Sep 2020 21:31:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Erik's part3 patch ensures that when the ObjectMonitor is allocated,
>> the weak handle is created and initialized to the oop at that point. Since
>> this is still the TSM version, the ObjectMonitor may not yet have a weak
>> handle allocated at the time that object() is called.
>
> Ok, this is cool then and good that this logic is here instead of inside the WeakHandle::resolve/peek functions.  The
> OopHandle similar functions have a null check, so if this was permanent, I'd suggest putting it there.  Since this is
> going to change, having it here and keeping the non-null invariants for WeakHandle::resolve/peek functions is better.

Thanks for confirmation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Fri Sep 11 21:45:14 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Sep 2020 21:45:14 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <FUxLEfUVidWZ2-LJlR4GoWIlAV61bDF-pyBSYl8fi98=.5c533df8-e93a-44ef-8620-ed90755b7030@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <FUxLEfUVidWZ2-LJlR4GoWIlAV61bDF-pyBSYl8fi98=.5c533df8-e93a-44ef-8620-ed90755b7030@github.com>
Message-ID: <C3fEfvgPuX4VsbtUMiWOcy42-TsypfgEgL-Wefp8KC0=.9be2e223-6211-45b9-acb7-563f8067f8d6@github.com>

On Fri, 11 Sep 2020 21:31:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Agreed.
>
> Ok, that's good then!

Thanks for confirmation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From lzang at openjdk.java.net  Sat Sep 12 00:17:58 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 12 Sep 2020 00:17:58 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <G7wEqabDpLMebETgcCafU0weoaujEB4VYL9YMp8XNX4=.8814ecf2-f9b3-48fe-97fa-59de5a0a92ba@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>
 <KybrQhWK_lSIFHMxPpyvr2--klhFMsAebgnsjVnU58I=.2d6e3024-f4ba-4814-b13d-a29226eba551@github.com>
 <P22B2myTT81fixG8IXWLu-8toxLF41sgfN5MQygJ0FA=.5811a18e-b210-41ca-8694-56601d8ee351@github.com>
 <3Z4xrVeHZ_d5Rcdn41HQUdMm9kdof-CSURtjFYn2lSg=.fa43943f-3175-43ef-8f8e-498ad6fe6512@github.com>
 <G7wEqabDpLMebETgcCafU0weoaujEB4VYL9YMp8XNX4=.8814ecf2-f9b3-48fe-97fa-59de5a0a92ba@github.com>
Message-ID: <Aht9s7WTezQC8tm5vs7zCCN5JA9nUG2VgZdv_pNt1hE=.38a95082-5f52-4735-ad39-ce85a569d014@github.com>

On Fri, 11 Sep 2020 13:54:38 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Thank you, we'll take a look next week.
>
> Hi Lin,
> 
> 1) The patch does not compile with assertion on
> @@ -1490,7 +1490,7 @@ private:
>        cl->do_object(obj);
>        obj->oop_iterate(&oops);
>      }
> -    assert(q.is_empty(), "should be empty");
> +    assert(q->is_empty(), "should be empty");
> 
> 2) I don't like to export following methods as public. Instead, you can declare ShenandoahParallelObjectIterator as
> friend class of ShenandoahHeap.
>    void scan_roots_for_iteration(Stack<oop, mtGC>* oop_stack, ObjectIterateScanRootClosure* oops);
>    bool prepare_aux_bitmap_for_iteration();
>    void reclaim_aux_bitmap_for_iteration();
> 
> 3) Please rename ObjectIterateParScanClosure to ShenandoahObjectIterateParScanClosure for code convention
> 
> 4) There is no point to seed mark roots if prepare_aux_bitmap_for_iteration() failed in
> ShenandoahParallelObjectIterator constructor.

Hi @zhengyu123 ,
Thanks for your comments!  I have refined the code and update the PR.
-Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From lzang at openjdk.java.net  Sat Sep 12 00:17:58 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 12 Sep 2020 00:17:58 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
Message-ID: <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>

> - enable parallel heap inspecton for ShenandoahHeap
>   - preliminary evaluation:
>     Time of jmap histo on (8GB heap with 4GB objects)
>     * before: 5.186s
>     * after : 1.698s

Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
will show differences compared to the previous content of the PR. The pull request contains one new commit since the
last revision:

  8252104: parallel heap inspection for ShenandoahHeap
  
    - enable parallel heap inspecton for ShenandoahHeap
    - preliminary evaluation:
      Time of jmap histo on (8GB heap with 4GB objects)
      * before: 5.186s
      * after : 1.698s

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/67/files
  - new: https://git.openjdk.java.net/jdk/pull/67/files/6645cc27..313d6cb5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=01-02

  Stats: 16 lines in 2 files changed: 7 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/67/head:pull/67

PR: https://git.openjdk.java.net/jdk/pull/67

From kim.barrett at oracle.com  Sat Sep 12 00:19:29 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 11 Sep 2020 20:19:29 -0400
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <5A831568-AD7A-4483-848C-F47D4A0115CD@oracle.com>

> On Sep 11, 2020, at 2:55 PM, Daniel D.Daugherty <dcubed at openjdk.java.net> wrote:
> 
> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>  void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.
> 
> -------------
> 
> Commit messages:
> - 8247281: migrate ObjectMonitor::_object to OopStorage
> 
> Changes: https://git.openjdk.java.net/jdk/pull/135/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8247281
>  Stats: 445 lines in 36 files changed: 108 ins; 234 del; 103 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/135.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/135/head:pull/135
> 
> PR: https://git.openjdk.java.net/jdk/pull/135


------------------------------------------------------------------------------
src/hotspot/share/oops/weakHandle.cpp
36 WeakHandle::WeakHandle(OopStorage* storage, oop obj) :
37   _obj(storage->allocate()) {
38   assert(obj != NULL, "no need to create weak null oop");

Please format this differently so the ctor-init-list is more easily
distinguished from the body.  I don't care that much which of the several
alternatives is used.

------------------------------------------------------------------------------  
src/hotspot/share/runtime/objectMonitor.cpp 
 244 // Check that object() and set_object() are called from the right context:
 245 static void check_object_context() {

This seems like checking we would normally only do in a debug build. Is this
really supposed to be done in product builds too? (It's written to support
that, just wondering if that's really what we want.) Maybe these aren't
called very often so it doesn't matter? I also see that guarantee (rather
than assert) is used a fair amount in this and related code.

------------------------------------------------------------------------------  
src/hotspot/share/runtime/objectMonitor.cpp 
 251     JavaThread* jt = (JavaThread*)self;

Use self->as_Java_thread().

Later: Coleen already commented on this and it's been fixed.

------------------------------------------------------------------------------ 
src/hotspot/share/runtime/objectMonitor.cpp 
 249   guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
 250   if (self->is_Java_thread()) {

Maybe instead

  if (self->is_Java_thread()) {
    ...
  } else {
    guarantee(self->is_VM_thread(), "must be");
  }

------------------------------------------------------------------------------
src/hotspot/share/runtime/objectMonitor.cpp 
Both ObjectMonitor::object() and ObjectMonitor::object_peek() have
 265   if (_object.is_null()) {
 266     return NULL;

Should we really be calling those functions when in such a state? That seems
like it might be a bug in the callers?

OK, I think I see some places where object_peek() might need such protection
because of races, in src/hotspot/share/runtime/synchronizer.cpp.  And
because we don't seem to ever release() the underlying WeakHandles.

514     if (m->object_peek() == NULL) {
703       if (cur_om->object_peek() == NULL) {

But it still seems like it might be a bug to call object() in such a state.

Related, see next comment.

Later: Looks like Coleen questioned this too.  I'm not sure I understand
Erik's response though.  When do we look at monitors that might not be
constructed / initialized?  That seems like a bad thing to do.  Oh, but the
whole creation path for OMs is kind of evil right now.  I see...  And that's
planned to be fixed in later work.  OK.

------------------------------------------------------------------------------
src/hotspot/share/runtime/synchronizer.cpp  
1548   guarantee(m->object_peek() == NULL, "invariant");

Later: But see previous comment.  Some of this might be relevat later though.

object_peek() seemed like the wrong operation here. I thought this was
attempting to verify that the underlying WeakHandle has been released. But
peeking doesn't ensure that.  Oh, but we don't actually release() the
WeakHandle when we "free" an OM.  We're just pushing the OM on the free
list.  Which means the GC will continue to examine the associated OopStorage
entry (and discover it's NULL).  So there's some cost to not releasing the
WeakHandle when putting an OM on the free list.  Of course, it means there
won't be any allocations when taking off the free list; I'm not sure which
way is better.

But this makes me go back and wonder about whether object_peek() should have
the _object.is_null() check.  After creation it seems like that should never
be true.

------------------------------------------------------------------------------
src/hotspot/share/runtime/synchronizer.cpp 

The old code in chk_in_use_entry seems wrong.  It checked for a null
object() and recorded that as an error.  But then it went on and attempted
to use it as if it was not null.  That's been fixed by the change.  However,
the change no longer treats a null as an error.  Probably this is because
it's weak, and so could have become null.  But is that really possible for
an "in use" monitor?

------------------------------------------------------------------------------
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java
 94   public OopHandle object() {
 95     Address objAddr = addr.getAddressAt(objectFieldOffset);
 96     if (objAddr == null) {
 97       return null;
 98     }
 99     return objAddr.getOopHandleAt(0);

How about something a little bit less abstraction smashing?

------------------------------------------------------------------------------


From dholmes at openjdk.java.net  Mon Sep 14 02:04:24 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Sep 2020 02:04:24 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
Message-ID: <0gKQJq1wgjTtGesVdOc7DGfjexnEkm_AcbNUSbYWSTk=.2b5edf85-1cb4-4818-92fe-c4dbf4535b6e@github.com>

On Fri, 11 Sep 2020 21:45:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - changes to resolve Coleen's comments.

Overall cleanup looks good. More complicated than I had expected, but then this changes the GC races with the deflation
code.

Not sure about the JVM TI changes!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dholmes at openjdk.java.net  Mon Sep 14 02:04:25 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Sep 2020 02:04:25 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <ifMkQC8OKpz5m6Bhx8o3WKKAm-Vaeei21ApmZVdoaw4=.41b2327b-9db1-4a5f-8f69-bba0488f40cc@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>
 <ifMkQC8OKpz5m6Bhx8o3WKKAm-Vaeei21ApmZVdoaw4=.41b2327b-9db1-4a5f-8f69-bba0488f40cc@github.com>
Message-ID: <4S1AuIQpJN081C7m_QDWkifv1yb7WHEzB_qbZ1IwWSA=.69fe7145-edad-46d9-bc48-e528489d3278@github.com>

On Fri, 11 Sep 2020 21:35:41 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 4593:
>> 
>>> 4591:   // are used in om_flush().
>>> 4592:   BarrierSet::barrier_set()->on_thread_detach(p);
>>> 4593:
>> 
>> One last question, that doesn't require a comment why it's here, but why was this moved?
>
> We had to move that code to make om_flush() happy.
> om_flush() accesses the (weak) oops in the monitor list
> after the thread is off the threads list so the barrier change
> had to move. It will move back in part3.

Just to be clear the thread is still on the threads_list at this point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dholmes at openjdk.java.net  Mon Sep 14 02:04:26 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Sep 2020 02:04:26 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <ExVVaITLKAVIH0GaprYE8g7xQ1GEAjChOAZGTGSO20o=.dc35b788-ffb7-40a6-850c-d80acc61ff9f@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <ExVVaITLKAVIH0GaprYE8g7xQ1GEAjChOAZGTGSO20o=.dc35b788-ffb7-40a6-850c-d80acc61ff9f@github.com>
Message-ID: <fIRORdoOh98JWKtHayhYzkIvG74kMAvQK5uMp3fiQFU=.280c4ce1-2ff1-4efe-9240-5335268e90e6@github.com>

On Fri, 11 Sep 2020 21:37:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Yes, exactly.
>
> Thanks for confirmation.

>From the spec I'm not clear on exactly what JVMTI_HEAP_REFERENCE_MONITOR is intended to be. Serviceability folk should
be giving some input here though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dholmes at openjdk.java.net  Mon Sep 14 02:04:25 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Sep 2020 02:04:25 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <C3fEfvgPuX4VsbtUMiWOcy42-TsypfgEgL-Wefp8KC0=.9be2e223-6211-45b9-acb7-563f8067f8d6@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <FUxLEfUVidWZ2-LJlR4GoWIlAV61bDF-pyBSYl8fi98=.5c533df8-e93a-44ef-8620-ed90755b7030@github.com>
 <C3fEfvgPuX4VsbtUMiWOcy42-TsypfgEgL-Wefp8KC0=.9be2e223-6211-45b9-acb7-563f8067f8d6@github.com>
Message-ID: <K_Bz_OELObm82PGeA614-ZycobMJsTq4POIr-pTMFAQ=.7dbde28b-d00b-4462-a8b5-9a94fed3c839@github.com>

On Fri, 11 Sep 2020 21:39:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Ok, that's good then!
>
> Thanks for confirmation.

I don't see anything in the HPROF format description that claims this is a strong root. At a minimum this seems to be a
behavioural change that would warrant a CSR request. This also seems to be something that the serviceability folk
should be made aware of and have a chance to comment on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dholmes at openjdk.java.net  Mon Sep 14 02:17:23 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Sep 2020 02:17:23 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <0gKQJq1wgjTtGesVdOc7DGfjexnEkm_AcbNUSbYWSTk=.2b5edf85-1cb4-4818-92fe-c4dbf4535b6e@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <0gKQJq1wgjTtGesVdOc7DGfjexnEkm_AcbNUSbYWSTk=.2b5edf85-1cb4-4818-92fe-c4dbf4535b6e@github.com>
Message-ID: <KBGv51iWJ3nmcY3LfASWXvRrkY0XxQnPl0GmMDKb95g=.c838c974-1f87-49dd-8aec-ad6c4651dbed@github.com>

On Mon, 14 Sep 2020 02:01:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - changes to resolve Coleen's comments.
>
> Overall cleanup looks good. More complicated than I had expected, but then this changes the GC races with the deflation
> code.
> Not sure about the JVM TI changes!

Please note that I made comments on the "resolved" discussion on heapDumper.cpp  and jvmtiTagMap.cpp  but they were not
mentioned in the review email and are hidden in the UI unless you explicitly click on "Show resolved".

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From david.holmes at oracle.com  Mon Sep 14 06:44:56 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Sep 2020 16:44:56 +1000
Subject: Integrated: 8243208: Clean up JVMFlag implementation
In-Reply-To: <AM4PR0202MB2964F428A774C898A88A9786EC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <CsaKHt4kDC9cSW6Gb9BOlIIrou8Eb5vXxBr87mJNXZQ=.a1c21d1a-a981-4140-bf69-4a3a179aefec@github.com>
 <AM4PR0202MB2964F428A774C898A88A9786EC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <a0fcde7b-31b2-82c6-03e4-201d714dc8fe@oracle.com>

Hi Goetz,

On 14/09/2020 4:13 pm, Lindenmaier, Goetz wrote:
> Hi,
> 
> Since this change was pushed, we see the following build error on Windows:
> .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220: warning treated as error - no 'object' file generated
> .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning C4307: '*': integral constant overflow
> 
> We are compiling with Microsoft Visual Studio 2017.
> 
> (Is it the right way to write a mail to bring this up, or
> should I comment the PullRequest or the like?)

You can write a mail or just file a bug. :)

Is this 32-bit Windows? We have not seen any issue in our 64-bit builds.

Thanks,
David


> Best regards,
>    Goetz
> 
>> -----Original Message-----
>> From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of Ioi
>> Lam
>> Sent: Friday, September 11, 2020 6:08 AM
>> To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net
>> Subject: Integrated: 8243208: Clean up JVMFlag implementation
>>
>> On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>>
>>> The initial commit
>> [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee
>> 9a92d10e1ac19d9bb2f8) is the
>>> same patch as
>>> [8243208-cleanup-jvmflag-
>> impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-
>> jvmflag-impl.v02/)
>>> published in
>>> [hotspot-
>> dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-
>> dev/2020-September/042863.html).  The
>>> rest of the review will continue on GitHub. I will add new commits to
>> respond to comments to the above e-mail.
>>
>> This pull request has now been integrated.
>>
>> Changeset: 5144190e
>> Author:    Ioi Lam <iklam at openjdk.org>
>> URL:       https://git.openjdk.java.net/jdk/commit/5144190e
>> Stats:     2127 lines in 45 files changed: 533 ins; 755 del; 839 mod
>>
>> 8243208: Clean up JVMFlag implementation
>>
>> Reviewed-by: dholmes, coleenp, gziemski
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/82

From david.holmes at oracle.com  Mon Sep 14 07:19:20 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Sep 2020 17:19:20 +1000
Subject: Integrated: 8243208: Clean up JVMFlag implementation
In-Reply-To: <AM4PR0202MB2964746D4E21B07C6665825CEC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <CsaKHt4kDC9cSW6Gb9BOlIIrou8Eb5vXxBr87mJNXZQ=.a1c21d1a-a981-4140-bf69-4a3a179aefec@github.com>
 <AM4PR0202MB2964F428A774C898A88A9786EC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <a0fcde7b-31b2-82c6-03e4-201d714dc8fe@oracle.com>
 <AM4PR0202MB2964746D4E21B07C6665825CEC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <0e5113fe-94fe-6471-ab80-94c9ff3358a8@oracle.com>

On 14/09/2020 5:02 pm, Lindenmaier, Goetz wrote:
> Hi David,
> 
> It fails in the 32 and 64-bit build with the same message.

We are building with VS2019, so may be a VS bug - possibly constExpr 
related. AFAICS line 54 is simply:

constexpr JVMFlagLookup _flag_lookup_table;

David

> Best regards,
>    Goetz
> 
> 
>> -----Original Message-----
>> From: David Holmes <david.holmes at oracle.com>
>> Sent: Monday, September 14, 2020 8:45 AM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Ioi Lam
>> <ioi.lam at oracle.com>; hotspot-dev at openjdk.java.net; shenandoah-
>> dev at openjdk.java.net
>> Subject: Re: Integrated: 8243208: Clean up JVMFlag implementation
>>
>> Hi Goetz,
>>
>> On 14/09/2020 4:13 pm, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> Since this change was pushed, we see the following build error on Windows:
>>> .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220:
>> warning treated as error - no 'object' file generated
>>> .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning
>> C4307: '*': integral constant overflow
>>>
>>> We are compiling with Microsoft Visual Studio 2017.
>>>
>>> (Is it the right way to write a mail to bring this up, or
>>> should I comment the PullRequest or the like?)
>>
>> You can write a mail or just file a bug. :)
>>
>> Is this 32-bit Windows? We have not seen any issue in our 64-bit builds.
>>
>> Thanks,
>> David
>>
>>
>>> Best regards,
>>>     Goetz
>>>
>>>> -----Original Message-----
>>>> From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of
>> Ioi
>>>> Lam
>>>> Sent: Friday, September 11, 2020 6:08 AM
>>>> To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net
>>>> Subject: Integrated: 8243208: Clean up JVMFlag implementation
>>>>
>>>> On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>>>>
>>>>> The initial commit
>>>>
>> [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee
>>>> 9a92d10e1ac19d9bb2f8) is the
>>>>> same patch as
>>>>> [8243208-cleanup-jvmflag-
>>>> impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-
>>>> jvmflag-impl.v02/)
>>>>> published in
>>>>> [hotspot-
>>>> dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-
>>>> dev/2020-September/042863.html).  The
>>>>> rest of the review will continue on GitHub. I will add new commits to
>>>> respond to comments to the above e-mail.
>>>>
>>>> This pull request has now been integrated.
>>>>
>>>> Changeset: 5144190e
>>>> Author:    Ioi Lam <iklam at openjdk.org>
>>>> URL:       https://git.openjdk.java.net/jdk/commit/5144190e
>>>> Stats:     2127 lines in 45 files changed: 533 ins; 755 del; 839 mod
>>>>
>>>> 8243208: Clean up JVMFlag implementation
>>>>
>>>> Reviewed-by: dholmes, coleenp, gziemski
>>>>
>>>> -------------
>>>>
>>>> PR: https://git.openjdk.java.net/jdk/pull/82

From iklam at openjdk.java.net  Mon Sep 14 07:31:01 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 14 Sep 2020 07:31:01 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v6]
In-Reply-To: <f2t24MvTqsFmQiNpN_f-iT65ed3NS5g8cAvYsX_4t50=.ac881a69-a469-4098-a6f3-290a22738b07@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com>
 <f2t24MvTqsFmQiNpN_f-iT65ed3NS5g8cAvYsX_4t50=.ac881a69-a469-4098-a6f3-290a22738b07@github.com>
Message-ID: <t1JA501kyrnZ9lG1p5InupxDGC2js8qzlHWji7_ip9A=.2d260b6c-c22f-4202-93e5-24f65b5789fd@github.com>

On Thu, 10 Sep 2020 15:32:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
>> the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last
>> revision:
>>  - Merge branch 'master' into 8243208-cleanup-jvmflag-impl
>>  - Minor code clean up suggested by David Holmes
>>  - Feedback by Gerard (hotspot-dev/2020-September/043019.html)
>>  - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit()
>>  - Fixed JVMFlag::is_writeable()
>>  - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(),
>>    (d) removed product_rw which is not used by any flags
>>  - 8243208: Clean up JVMFlag implementation
>
> Marked as reviewed by gziemski (Committer).

Maybe it's complaining about this "*" in jvmFlagLookup.hpp? How about this:

  static constexpr unsigned int hash_code(const char* s, size_t len) {
    unsigned int h = 0;
    while (len -- > 0) {
-     h = 31*h + (unsigned int) *s;
+     h = ((unsigned int)31)*h + (unsigned int) *s;
      s++;
    }
    return h;

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From shade at openjdk.java.net  Mon Sep 14 07:41:57 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 14 Sep 2020 07:41:57 GMT
Subject: RFR: 8243208: Clean up JVMFlag implementation [v6]
In-Reply-To: <t1JA501kyrnZ9lG1p5InupxDGC2js8qzlHWji7_ip9A=.2d260b6c-c22f-4202-93e5-24f65b5789fd@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com>
 <f2t24MvTqsFmQiNpN_f-iT65ed3NS5g8cAvYsX_4t50=.ac881a69-a469-4098-a6f3-290a22738b07@github.com>
 <t1JA501kyrnZ9lG1p5InupxDGC2js8qzlHWji7_ip9A=.2d260b6c-c22f-4202-93e5-24f65b5789fd@github.com>
Message-ID: <MLXuSqwed4o8XpNigxDgA504DrOwCHKClNvCnLFP6_4=.111d67db-1e08-4f9e-a02e-8e324866176a@github.com>

On Mon, 14 Sep 2020 07:28:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Marked as reviewed by gziemski (Committer).
>
> Maybe it's complaining about this "*" in jvmFlagLookup.hpp? How about this:
> 
>   static constexpr unsigned int hash_code(const char* s, size_t len) {
>     unsigned int h = 0;
>     while (len -- > 0) {
> -     h = 31*h + (unsigned int) *s;
> +     h = ((unsigned int)31)*h + (unsigned int) *s;
>       s++;
>     }
>     return h;

Seeing Windows build failures on some of my Windows build nodes as well. Filed
https://bugs.openjdk.java.net/browse/JDK-8253089, please discuss there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/82

From stefank at openjdk.java.net  Mon Sep 14 08:20:30 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 14 Sep 2020 08:20:30 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
Message-ID: <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>

On Fri, 11 Sep 2020 21:45:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - changes to resolve Coleen's comments.

GC changes looks good to me.

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/135

From rkennke at openjdk.java.net  Mon Sep 14 11:35:41 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 14 Sep 2020 11:35:41 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
Message-ID: <umSc_tZhpRBXFGGwedmaaW3CWnZOdQVPM_C6LGLZ9iQ=.7c4abee0-cf5e-45ca-a9a0-80fc4c52e0f3@github.com>

On Mon, 14 Sep 2020 08:18:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - changes to resolve Coleen's comments.
>
> GC changes looks good to me.

Shenandoah changes are not complete:


           ObjectSynchronizer::oops_do(&resolve_mark_cl);
                               ^~~~~~~

           ObjectSynchronizer::oops_do(&mark_cl);
                               ^~~~~~~

I will have a look into how to resolve this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From goetz.lindenmaier at sap.com  Mon Sep 14 06:13:43 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 14 Sep 2020 06:13:43 +0000
Subject: Integrated: 8243208: Clean up JVMFlag implementation
In-Reply-To: <CsaKHt4kDC9cSW6Gb9BOlIIrou8Eb5vXxBr87mJNXZQ=.a1c21d1a-a981-4140-bf69-4a3a179aefec@github.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <CsaKHt4kDC9cSW6Gb9BOlIIrou8Eb5vXxBr87mJNXZQ=.a1c21d1a-a981-4140-bf69-4a3a179aefec@github.com>
Message-ID: <AM4PR0202MB2964F428A774C898A88A9786EC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

Since this change was pushed, we see the following build error on Windows:
.../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220: warning treated as error - no 'object' file generated
.../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning C4307: '*': integral constant overflow

We are compiling with Microsoft Visual Studio 2017.

(Is it the right way to write a mail to bring this up, or 
should I comment the PullRequest or the like?)

Best regards,
  Goetz

> -----Original Message-----
> From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of Ioi
> Lam
> Sent: Friday, September 11, 2020 6:08 AM
> To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net
> Subject: Integrated: 8243208: Clean up JVMFlag implementation
> 
> On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> 
> > The initial commit
> [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee
> 9a92d10e1ac19d9bb2f8) is the
> > same patch as
> > [8243208-cleanup-jvmflag-
> impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-
> jvmflag-impl.v02/)
> > published in
> > [hotspot-
> dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-
> dev/2020-September/042863.html).  The
> > rest of the review will continue on GitHub. I will add new commits to
> respond to comments to the above e-mail.
> 
> This pull request has now been integrated.
> 
> Changeset: 5144190e
> Author:    Ioi Lam <iklam at openjdk.org>
> URL:       https://git.openjdk.java.net/jdk/commit/5144190e
> Stats:     2127 lines in 45 files changed: 533 ins; 755 del; 839 mod
> 
> 8243208: Clean up JVMFlag implementation
> 
> Reviewed-by: dholmes, coleenp, gziemski
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/82

From goetz.lindenmaier at sap.com  Mon Sep 14 07:02:28 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 14 Sep 2020 07:02:28 +0000
Subject: Integrated: 8243208: Clean up JVMFlag implementation
In-Reply-To: <a0fcde7b-31b2-82c6-03e4-201d714dc8fe@oracle.com>
References: <hJvQ81Mwrfasyeldtzev2qyhJDRx-tBT5HA1jdxxw3s=.2c2a375e-e88f-4186-b41c-7db06cbbb9af@github.com>
 <CsaKHt4kDC9cSW6Gb9BOlIIrou8Eb5vXxBr87mJNXZQ=.a1c21d1a-a981-4140-bf69-4a3a179aefec@github.com>
 <AM4PR0202MB2964F428A774C898A88A9786EC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <a0fcde7b-31b2-82c6-03e4-201d714dc8fe@oracle.com>
Message-ID: <AM4PR0202MB2964746D4E21B07C6665825CEC230@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi David, 

It fails in the 32 and 64-bit build with the same message.

Best regards,
  Goetz


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Monday, September 14, 2020 8:45 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Ioi Lam
> <ioi.lam at oracle.com>; hotspot-dev at openjdk.java.net; shenandoah-
> dev at openjdk.java.net
> Subject: Re: Integrated: 8243208: Clean up JVMFlag implementation
> 
> Hi Goetz,
> 
> On 14/09/2020 4:13 pm, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Since this change was pushed, we see the following build error on Windows:
> > .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220:
> warning treated as error - no 'object' file generated
> > .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning
> C4307: '*': integral constant overflow
> >
> > We are compiling with Microsoft Visual Studio 2017.
> >
> > (Is it the right way to write a mail to bring this up, or
> > should I comment the PullRequest or the like?)
> 
> You can write a mail or just file a bug. :)
> 
> Is this 32-bit Windows? We have not seen any issue in our 64-bit builds.
> 
> Thanks,
> David
> 
> 
> > Best regards,
> >    Goetz
> >
> >> -----Original Message-----
> >> From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of
> Ioi
> >> Lam
> >> Sent: Friday, September 11, 2020 6:08 AM
> >> To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net
> >> Subject: Integrated: 8243208: Clean up JVMFlag implementation
> >>
> >> On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> >>
> >>> The initial commit
> >>
> [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee
> >> 9a92d10e1ac19d9bb2f8) is the
> >>> same patch as
> >>> [8243208-cleanup-jvmflag-
> >> impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-
> >> jvmflag-impl.v02/)
> >>> published in
> >>> [hotspot-
> >> dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-
> >> dev/2020-September/042863.html).  The
> >>> rest of the review will continue on GitHub. I will add new commits to
> >> respond to comments to the above e-mail.
> >>
> >> This pull request has now been integrated.
> >>
> >> Changeset: 5144190e
> >> Author:    Ioi Lam <iklam at openjdk.org>
> >> URL:       https://git.openjdk.java.net/jdk/commit/5144190e
> >> Stats:     2127 lines in 45 files changed: 533 ins; 755 del; 839 mod
> >>
> >> 8243208: Clean up JVMFlag implementation
> >>
> >> Reviewed-by: dholmes, coleenp, gziemski
> >>
> >> -------------
> >>
> >> PR: https://git.openjdk.java.net/jdk/pull/82

From dcubed at openjdk.java.net  Mon Sep 14 13:43:01 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 13:43:01 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <4S1AuIQpJN081C7m_QDWkifv1yb7WHEzB_qbZ1IwWSA=.69fe7145-edad-46d9-bc48-e528489d3278@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <HZ52Mh9J3BRoOUbRHbBPB882sJgNKtlkdxrG20pWEb4=.cf1276cf-ad31-4b85-96c9-22d5a91a502f@github.com>
 <ifMkQC8OKpz5m6Bhx8o3WKKAm-Vaeei21ApmZVdoaw4=.41b2327b-9db1-4a5f-8f69-bba0488f40cc@github.com>
 <4S1AuIQpJN081C7m_QDWkifv1yb7WHEzB_qbZ1IwWSA=.69fe7145-edad-46d9-bc48-e528489d3278@github.com>
Message-ID: <xYldHPrkkMHelvA2MhOr6csHhrdZiNAQmk5EkdaESqM=.b4116a34-82b6-4d50-a019-c9a3134072ef@github.com>

On Mon, 14 Sep 2020 01:43:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We had to move that code to make om_flush() happy.
>> om_flush() accesses the (weak) oops in the monitor list
>> after the thread is off the threads list so the barrier change
>> had to move. It will move back in part3.
>
> Just to be clear the thread is still on the threads_list at this point.

Sorry, I should have been more clear here.
We had to move that code after the om_flush() call because om_flush()
accesses the (weak) oops in the monitor list after the original location
of the code. The om_flush() call is made in the code that removes the
thread from the threads list, but the removal happens after the call to
om_flush().

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 13:50:31 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 13:50:31 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
Message-ID: <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>

On Mon, 14 Sep 2020 08:18:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - changes to resolve Coleen's comments.
>
> GC changes looks good to me.

@stefank - Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 13:50:31 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 13:50:31 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
Message-ID: <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>

On Mon, 14 Sep 2020 13:45:16 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> GC changes looks good to me.
>
> @stefank - Thanks for the review!

@dholmes-ora - Thanks for the review. I've think I have made all the comments
you were concerned about as unresolved. I agree that we need a CSR for the
change in behavior and I'll look into getting that going.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 13:50:31 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 13:50:31 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
Message-ID: <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>

On Mon, 14 Sep 2020 13:47:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @dholmes-ora - Thanks for the review. I've think I have made all the comments
>> you were concerned about as unresolved. I agree that we need a CSR for the
>> change in behavior and I'll look into getting that going.
>
> @kimbarrett - Thanks for the review. I believe @fisk is going to
> address your comments.

@rkennke - Thanks for the review. I believe @fisk is going to address
your comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 13:50:31 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 13:50:31 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
Message-ID: <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>

On Mon, 14 Sep 2020 13:46:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @stefank - Thanks for the review!
>
> @dholmes-ora - Thanks for the review. I've think I have made all the comments
> you were concerned about as unresolved. I agree that we need a CSR for the
> change in behavior and I'll look into getting that going.

@kimbarrett - Thanks for the review. I believe @fisk is going to
address your comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Mon Sep 14 14:18:27 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 14 Sep 2020 14:18:27 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
Message-ID: <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>

On Mon, 14 Sep 2020 13:48:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @kimbarrett - Thanks for the review. I believe @fisk is going to
>> address your comments.
>
> @rkennke - Thanks for the review. I believe @fisk is going to address
> your comments.

Hi Kim,

Here is a partial reply to your review. Thanks for reviewing!
Hmm seems like your email was only sent to shenandoah-dev. Not sure if that was intended. I'm not subscribed to that
mailing list, so I will send my reply through github and hope for the best.

> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on
> [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_
> ------------------------------------------------------------------------------
> src/hotspot/share/oops/weakHandle.cpp
> 36 WeakHandle::WeakHandle(OopStorage* storage, oop obj) :
> 37 _obj(storage->allocate()) {
> 38 assert(obj != NULL, "no need to create weak null oop");
> 
> Please format this differently so the ctor-init-list is more easily
> distinguished from the body. I don't care that much which of the several
> alternatives is used.
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/objectMonitor.cpp
> 244 // Check that object() and set_object() are called from the right context:
> 245 static void check_object_context() {
> 
> This seems like checking we would normally only do in a debug build. Is this
> really supposed to be done in product builds too? (It's written to support
> that, just wondering if that's really what we want.) Maybe these aren't
> called very often so it doesn't matter? I also see that guarantee (rather
> than assert) is used a fair amount in this and related code.

I don't think I have a preference here. As you say, it seems a bit mixed. I would be okay with both. Do you want them
to be asserts?

> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/objectMonitor.cpp
> 251 JavaThread* jt = (JavaThread*)self;
> 
> Use self->as_Java_thread().
> 
> Later: Coleen already commented on this and it's been fixed.
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/objectMonitor.cpp
> 249 guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
> 250 if (self->is_Java_thread()) {
> 
> Maybe instead
> 
> if (self->is_Java_thread()) {
> ...
> } else {
> guarantee(self->is_VM_thread(), "must be");
> }
> 
> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/objectMonitor.cpp
> Both ObjectMonitor::object() and ObjectMonitor::object_peek() have
> 265 if (_object.is_null()) {
> 266 return NULL;
> 
> Should we really be calling those functions when in such a state? That seems
> like it might be a bug in the callers?
> 
> OK, I think I see some places where object_peek() might need such protection
> because of races, in src/hotspot/share/runtime/synchronizer.cpp. And
> because we don't seem to ever release() the underlying WeakHandles.
> 
> 514 if (m->object_peek() == NULL) {
> 703 if (cur_om->object_peek() == NULL) {
> 
> But it still seems like it might be a bug to call object() in such a state.

The problem is Type Stable Memory (TSM). The idea is that all monitors are allocated in blocks of many (when the object
they are associated with is not yet known), and are then re-used, switching object association back and forth. They are
also never freed.

The changes in this RFR were originally tied together with a patch that also removes TSM. But this has been split into
separate parts by Dan in order to perform the OopStorage migration first, and then removing TSM. So in this patch, we
are still dealing with block-allocation of monitors before they have an associated object, and changing of object
association. Therefore, what you are saying is 100% true, but I would like to defer fixing that until the follow-up
patch that removes TSM. In that patch, the accessors are changed to do exactly what you expect them to (resolve/peek),
as the ObjectMonitor instances are allocated with a single object association in mind, installed in the constructor,
and get deleted after deflation, with destuctors run. So I hope we can agree to wait until that subsequent patch with
addressing such concerns. We thought reviewing the whole thing as a single patch was too much clutter.

> Related, see next comment.
> 
> Later: Looks like Coleen questioned this too. I'm not sure I understand
> Erik's response though. When do we look at monitors that might not be
> constructed / initialized? That seems like a bad thing to do. Oh, but the
> whole creation path for OMs is kind of evil right now. I see... And that's
> planned to be fixed in later work. OK.

Yes, exactly. It is currently quite evil, but will soon be cleaned up to look quite ordinary.

> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/synchronizer.cpp
> 1548 guarantee(m->object_peek() == NULL, "invariant");
> 
> Later: But see previous comment. Some of this might be relevat later though.
> 
> object_peek() seemed like the wrong operation here. I thought this was
> attempting to verify that the underlying WeakHandle has been released. But
> peeking doesn't ensure that. Oh, but we don't actually release() the
> WeakHandle when we "free" an OM. We're just pushing the OM on the free
> list. Which means the GC will continue to examine the associated OopStorage
> entry (and discover it's NULL). So there's some cost to not releasing the
> WeakHandle when putting an OM on the free list. Of course, it means there
> won't be any allocations when taking off the free list; I'm not sure which
> way is better.

Yeah, so we never really release the monitors, because the whole monitor can't be freed yet in this patch.

> But this makes me go back and wonder about whether object_peek() should have
> the _object.is_null() check. After creation it seems like that should never
> be true.

Before the switch away from TSM (next patch), we must assume that monitors have not yet been properly initialized, due
to block allocation of a whole bunch of monitors at a time, before they have been associated with objects. They are
also exposed to iterators and such, before any object association has been made. But very very soon, that will be a
memory of the past.

> ------------------------------------------------------------------------------
> src/hotspot/share/runtime/synchronizer.cpp
> 
> The old code in chk_in_use_entry seems wrong. It checked for a null
> object() and recorded that as an error. But then it went on and attempted
> to use it as if it was not null. That's been fixed by the change. However,
> the change no longer treats a null as an error. Probably this is because
> it's weak, and so could have become null. But is that really possible for
> an "in use" monitor?

Well, the monitors are added to some in-use list at deflation time. The instant after, the monitor could have become
unused. But it will still be floating around on the in-use list, until deflation time. And yes, now it is suddenly very
much valid for a monitor that is no longer used (but placed on the in-use list when it was used), to have a NULL
object, due to GC getting to weak processing clearing the oop, before deflation gets to it.

> ------------------------------------------------------------------------------
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java
> 94 public OopHandle object() {
> 95 Address objAddr = addr.getAddressAt(objectFieldOffset);
> 96 if (objAddr == null) {
> 97 return null;
> 98 }
> 99 return objAddr.getOopHandleAt(0);
> 
> How about something a little bit less abstraction smashing?

This is already the "norm", and the way that all other handle loads look in the SA today, and therefore the SA does not
support any GC with load barriers properly. While ideally, there would be something equivalent to the Access API in the
SA to abstract the access details, I think it seems like way beyond the scope of this change to implement something
like that for the SA, as part of this change.

Again, thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Mon Sep 14 14:23:23 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 14 Sep 2020 14:23:23 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
Message-ID: <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>

On Mon, 14 Sep 2020 14:15:41 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> @rkennke - Thanks for the review. I believe @fisk is going to address
>> your comments.
>
> Hi Kim,
> 
> Here is a partial reply to your review. Thanks for reviewing!
> Hmm seems like your email was only sent to shenandoah-dev. Not sure if that was intended. I'm not subscribed to that
> mailing list, so I will send my reply through github and hope for the best.
>> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on
>> [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_
>> ------------------------------------------------------------------------------
>> src/hotspot/share/oops/weakHandle.cpp
>> 36 WeakHandle::WeakHandle(OopStorage* storage, oop obj) :
>> 37 _obj(storage->allocate()) {
>> 38 assert(obj != NULL, "no need to create weak null oop");
>> 
>> Please format this differently so the ctor-init-list is more easily
>> distinguished from the body. I don't care that much which of the several
>> alternatives is used.
>> 
>> ------------------------------------------------------------------------------
>> src/hotspot/share/runtime/objectMonitor.cpp
>> 244 // Check that object() and set_object() are called from the right context:
>> 245 static void check_object_context() {
>> 
>> This seems like checking we would normally only do in a debug build. Is this
>> really supposed to be done in product builds too? (It's written to support
>> that, just wondering if that's really what we want.) Maybe these aren't
>> called very often so it doesn't matter? I also see that guarantee (rather
>> than assert) is used a fair amount in this and related code.
> 
> I don't think I have a preference here. As you say, it seems a bit mixed. I would be okay with both. Do you want them
> to be asserts?
>> ------------------------------------------------------------------------------
>> src/hotspot/share/runtime/objectMonitor.cpp
>> 251 JavaThread* jt = (JavaThread*)self;
>> 
>> Use self->as_Java_thread().
>> 
>> Later: Coleen already commented on this and it's been fixed.
>> 
>> ------------------------------------------------------------------------------
>> src/hotspot/share/runtime/objectMonitor.cpp
>> 249 guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
>> 250 if (self->is_Java_thread()) {
>> 
>> Maybe instead
>> 
>> if (self->is_Java_thread()) {
>> ...
>> } else {
>> guarantee(self->is_VM_thread(), "must be");
>> }
>> 
>> ------------------------------------------------------------------------------
>> src/hotspot/share/runtime/objectMonitor.cpp
>> Both ObjectMonitor::object() and ObjectMonitor::object_peek() have
>> 265 if (_object.is_null()) {
>> 266 return NULL;
>> 
>> Should we really be calling those functions when in such a state? That seems
>> like it might be a bug in the callers?
>> 
>> OK, I think I see some places where object_peek() might need such protection
>> because of races, in src/hotspot/share/runtime/synchronizer.cpp. And
>> because we don't seem to ever release() the underlying WeakHandles.
>> 
>> 514 if (m->object_peek() == NULL) {
>> 703 if (cur_om->object_peek() == NULL) {
>> 
>> But it still seems like it might be a bug to call object() in such a state.
> 
> The problem is Type Stable Memory (TSM). The idea is that all monitors are allocated in blocks of many (when the object
> they are associated with is not yet known), and are then re-used, switching object association back and forth. They are
> also never freed.  The changes in this RFR were originally tied together with a patch that also removes TSM. But this
> has been split into separate parts by Dan in order to perform the OopStorage migration first, and then removing TSM. So
> in this patch, we are still dealing with block-allocation of monitors before they have an associated object, and
> changing of object association. Therefore, what you are saying is 100% true, but I would like to defer fixing that
> until the follow-up patch that removes TSM. In that patch, the accessors are changed to do exactly what you expect them
> to (resolve/peek), as the ObjectMonitor instances are allocated with a single object association in mind, installed in
> the constructor, and get deleted after deflation, with destuctors run. So I hope we can agree to wait until that
> subsequent patch with addressing such concerns. We thought reviewing the whole thing as a single patch was too much
> clutter.
>> Related, see next comment.
>> 
>> Later: Looks like Coleen questioned this too. I'm not sure I understand
>> Erik's response though. When do we look at monitors that might not be
>> constructed / initialized? That seems like a bad thing to do. Oh, but the
>> whole creation path for OMs is kind of evil right now. I see... And that's
>> planned to be fixed in later work. OK.
> 
> Yes, exactly. It is currently quite evil, but will soon be cleaned up to look quite ordinary.
> 
>> ------------------------------------------------------------------------------
>> src/hotspot/share/runtime/synchronizer.cpp
>> 1548 guarantee(m->object_peek() == NULL, "invariant");
>> 
>> Later: But see previous comment. Some of this might be relevat later though.
>> 
>> object_peek() seemed like the wrong operation here. I thought this was
>> attempting to verify that the underlying WeakHandle has been released. But
>> peeking doesn't ensure that. Oh, but we don't actually release() the
>> WeakHandle when we "free" an OM. We're just pushing the OM on the free
>> list. Which means the GC will continue to examine the associated OopStorage
>> entry (and discover it's NULL). So there's some cost to not releasing the
>> WeakHandle when putting an OM on the free list. Of course, it means there
>> won't be any allocations when taking off the free list; I'm not sure which
>> way is better.
> 
> Yeah, so we never really release the monitors, because the whole monitor can't be freed yet in this patch.
> 
>> But this makes me go back and wonder about whether object_peek() should have
>> the _object.is_null() check. After creation it seems like that should never
>> be true.
> 
> Before the switch away from TSM (next patch), we must assume that monitors have not yet been properly initialized, due
> to block allocation of a whole bunch of monitors at a time, before they have been associated with objects. They are
> also exposed to iterators and such, before any object association has been made. But very very soon, that will be a
> memory of the past.
>> ------------------------------------------------------------------------------
>> src/hotspot/share/runtime/synchronizer.cpp
>> 
>> The old code in chk_in_use_entry seems wrong. It checked for a null
>> object() and recorded that as an error. But then it went on and attempted
>> to use it as if it was not null. That's been fixed by the change. However,
>> the change no longer treats a null as an error. Probably this is because
>> it's weak, and so could have become null. But is that really possible for
>> an "in use" monitor?
> 
> Well, the monitors are added to some in-use list at deflation time. The instant after, the monitor could have become
> unused. But it will still be floating around on the in-use list, until deflation time. And yes, now it is suddenly very
> much valid for a monitor that is no longer used (but placed on the in-use list when it was used), to have a NULL
> object, due to GC getting to weak processing clearing the oop, before deflation gets to it.
>> ------------------------------------------------------------------------------
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java
>> 94 public OopHandle object() {
>> 95 Address objAddr = addr.getAddressAt(objectFieldOffset);
>> 96 if (objAddr == null) {
>> 97 return null;
>> 98 }
>> 99 return objAddr.getOopHandleAt(0);
>> 
>> How about something a little bit less abstraction smashing?
> 
> This is already the "norm", and the way that all other handle loads look in the SA today, and therefore the SA does not
> support any GC with load barriers properly. While ideally, there would be something equivalent to the Access API in the
> SA to abstract the access details, I think it seems like way beyond the scope of this change to implement something
> like that for the SA, as part of this change.  Again, thanks for reviewing!

> Shenandoah changes are not complete:
> /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp: In member function 'virtual
> void ShenandoahFinalMarkingTask::work(uint)':
> /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:298:31: error: 'oops_do' is
> not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&resolve_mark_cl); ^~~~~~~
> /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:308:31: error: 'oops_do' is
> not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&mark_cl);
> ^~~~~~~
> 
> I will have a look into how to resolve this.
> 
> In order to fix this, I need one of two things:
> 
>     * A way to iterate oops of the global-list. Explanation: In Shenandoah's I-U mode, we need to re-mark such ObjectMonitors
>       during final-mark because they may be the only remaining reference to an object on the heap.
>       _or_ (even better)
> 
>     * Call a write-barrier (IN_NATIVE) whenever an ObjectMonitor is moved to the global-list upon thread-destruction. This
>       way we could mark that object concurrently.
> 
> 
> Notice that this does not affect thread-local ObjectMonitors (IOW, most regular ObjectMonitors) because those would be
> scanned while scanning thread stacks. Therefore I'd like to avoid to generally place a barrier in ObjectMonitor.
> See: https://bugs.openjdk.java.net/browse/JDK-8251451
> 
> AFAICT, this may affect ZGC too (not 100% sure about this).

So this change makes the object monitors weak. So you shouldn't have to remark them at all. If they hold the last
reference to the object, then the monitor gets the object cleared as part of normal weak OopStorage reference
processing. Subsequent deflation cycles will detect that the GC has cleared the oop, and reuse the monitor. In other
words, we should just remove the call to the oops_do function, and rely on OopStorage doing its thing. The GC should
not have to care at all about monitors any longer, only about processing weak OopStorages, which is done automatically.
Hope this makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From rkennke at openjdk.java.net  Mon Sep 14 14:26:26 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 14 Sep 2020 14:26:26 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
Message-ID: <WvluCbaJ0HsDbg8GKdKuvBuYTSC0JylEqdQgiLfkXY4=.4adefa62-d626-48ad-9af8-57705b545422@github.com>

On Mon, 14 Sep 2020 13:48:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> @rkennke - Thanks for the review. I believe @fisk is going to address
> your comments.

Actually, if I understand it correctly, OopStorage already gives us full barriers, so we should be covered, and we can
simply revert JDK-8251451: http://cr.openjdk.java.net/~rkennke/8247281-shenandoah.patch
(Is there a better way to propose amendments to a PR?!)

I believe this probably also means that we don't need to scan object monitor lists during thread-scans, and let SATB
(or whatever concurrent marking) take care of it. @fisk WDYT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From rkennke at openjdk.java.net  Mon Sep 14 14:40:18 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 14 Sep 2020 14:40:18 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
Message-ID: <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>

On Mon, 14 Sep 2020 14:20:29 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > Shenandoah changes are not complete:
> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp: In member function 'virtual
> > void ShenandoahFinalMarkingTask::work(uint)':
> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:298:31: error: 'oops_do' is
> > not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&resolve_mark_cl); ^~~~~~~
> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:308:31: error: 'oops_do' is
> > not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&mark_cl);
> > ^~~~~~~
> > I will have a look into how to resolve this.
> > In order to fix this, I need one of two things:
> > ```
> > * A way to iterate oops of the global-list. Explanation: In Shenandoah's I-U mode, we need to re-mark such ObjectMonitors
> >   during final-mark because they may be the only remaining reference to an object on the heap.
> >   _or_ (even better)
> > 
> > * Call a write-barrier (IN_NATIVE) whenever an ObjectMonitor is moved to the global-list upon thread-destruction. This
> >   way we could mark that object concurrently.
> > ```
> > 
> > 
> > Notice that this does not affect thread-local ObjectMonitors (IOW, most regular ObjectMonitors) because those would be
> > scanned while scanning thread stacks. Therefore I'd like to avoid to generally place a barrier in ObjectMonitor. See:
> > https://bugs.openjdk.java.net/browse/JDK-8251451 AFAICT, this may affect ZGC too (not 100% sure about this).
> 
> So this change makes the object monitors weak. So you shouldn't have to remark them at all. If they hold the last
> reference to the object, then the monitor gets the object cleared as part of normal weak OopStorage reference
> processing. Subsequent deflation cycles will detect that the GC has cleared the oop, and reuse the monitor. In other
> words, we should just remove the call to the oops_do function, and rely on OopStorage doing its thing. The GC should
> not have to care at all about monitors any longer, only about processing weak OopStorages, which is done automatically.
> Hope this makes sense.

Yes, definitely. I came to the same conclusion. Thank you!
With the patch amended:
http://cr.openjdk.java.net/~rkennke/8247281-shenandoah.patch

I'm good with the change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Mon Sep 14 14:40:18 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 14 Sep 2020 14:40:18 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <0gKQJq1wgjTtGesVdOc7DGfjexnEkm_AcbNUSbYWSTk=.2b5edf85-1cb4-4818-92fe-c4dbf4535b6e@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <0gKQJq1wgjTtGesVdOc7DGfjexnEkm_AcbNUSbYWSTk=.2b5edf85-1cb4-4818-92fe-c4dbf4535b6e@github.com>
Message-ID: <eJSkj8IQOxpb1CiO4N1b_C8tuUZ4XiEMZkg5yFDdOJ4=.c70aa8dd-a59e-4d85-80d1-4f26b14d3d3e@github.com>

On Mon, 14 Sep 2020 02:01:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Not sure about the JVM TI changes!

Here is a generic comment. You mention that the specification doesn't make it clear whether the roots reported are
strong or weak. This is true. There is no mention about roots being strong or weak here. Notably, all listed roots, are
strong though. I believe that with the chosen interpretation of "root", it is implied that it is strong, and hence why
strong vs weak roots is not discussed. According to the memory management glossary
(https://www.memorymanagement.org/glossary/r.html#glossary-r), this is the definition of a root: "In tracing garbage
collection, a root holds a reference or set of references to objects that are a priori reachable. The root set is used
as the starting point in determining all reachable data." Note that, this definition of root makes it implicit that it
is also strong. And after a long discussion with GC nerds in Stockholm, this is in fact also why we have IN_NATIVE oop
accesses, rather than IN_ROOT oop accesses. Because the opinions differed too much about what a "root" is. But to me it
really does look like the JVMTI interpretation of a root, is a strong root, and hence that this is precisely what the
text is talking about when mentioning roots, and hence also why all the enumerated roots, are indeed strong roots. Same
comments for the HPROF_GC_ROOT_* discussion, as for the JVMTI_HEAP_ROOT_* discussion. That is also why I think it is
now a bug to report them, as they are no longer "roots" in the JVMTI/HPROF sense. But you are right, filing a CSR for
the behavioural change is probably a good idea.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Mon Sep 14 14:43:38 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 14 Sep 2020 14:43:38 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <WvluCbaJ0HsDbg8GKdKuvBuYTSC0JylEqdQgiLfkXY4=.4adefa62-d626-48ad-9af8-57705b545422@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <WvluCbaJ0HsDbg8GKdKuvBuYTSC0JylEqdQgiLfkXY4=.4adefa62-d626-48ad-9af8-57705b545422@github.com>
Message-ID: <qExzWYdycx34UPmS0DdQ2fBImarvAWP3-Z8_JDVI3Xo=.4a177e58-a9a8-4510-a135-2de623f9e12e@github.com>

On Mon, 14 Sep 2020 14:24:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > @rkennke - Thanks for the review. I believe @fisk is going to address
> > your comments.
> 
> Actually, if I understand it correctly, OopStorage already gives us full barriers, so we should be covered, and we can
> simply revert JDK-8251451: http://cr.openjdk.java.net/~rkennke/8247281-shenandoah.patch
> (Is there a better way to propose amendments to a PR?!)
> 
> I believe this probably also means that we don't need to scan object monitor lists during thread-scans, and let SATB
> (or whatever concurrent marking) take care of it. @fisk WDYT?

Absolutely. GC should no longer have to know anything about ObjectMonitors, only the automatically plugged in
OopStorage that it processes. GC should not walk any monitor lists at all.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 16:19:48 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 16:19:48 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
Message-ID: <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW492Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>

On Mon, 14 Sep 2020 14:27:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> Shenandoah changes are not complete:
>>> /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp: In member function 'virtual
>>> void ShenandoahFinalMarkingTask::work(uint)':
>>> /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:298:31: error: 'oops_do' is
>>> not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&resolve_mark_cl); ^~~~~~~
>>> /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:308:31: error: 'oops_do' is
>>> not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&mark_cl);
>>> ^~~~~~~
>>> 
>>> I will have a look into how to resolve this.
>>> 
>>> In order to fix this, I need one of two things:
>>> 
>>>     * A way to iterate oops of the global-list. Explanation: In Shenandoah's I-U mode, we need to re-mark such ObjectMonitors
>>>       during final-mark because they may be the only remaining reference to an object on the heap.
>>>       _or_ (even better)
>>> 
>>>     * Call a write-barrier (IN_NATIVE) whenever an ObjectMonitor is moved to the global-list upon thread-destruction. This
>>>       way we could mark that object concurrently.
>>> 
>>> 
>>> Notice that this does not affect thread-local ObjectMonitors (IOW, most regular ObjectMonitors) because those would be
>>> scanned while scanning thread stacks. Therefore I'd like to avoid to generally place a barrier in ObjectMonitor.
>>> See: https://bugs.openjdk.java.net/browse/JDK-8251451
>>> 
>>> AFAICT, this may affect ZGC too (not 100% sure about this).
>> 
>> So this change makes the object monitors weak. So you shouldn't have to remark them at all. If they hold the last
>> reference to the object, then the monitor gets the object cleared as part of normal weak OopStorage reference
>> processing. Subsequent deflation cycles will detect that the GC has cleared the oop, and reuse the monitor. In other
>> words, we should just remove the call to the oops_do function, and rely on OopStorage doing its thing. The GC should
>> not have to care at all about monitors any longer, only about processing weak OopStorages, which is done automatically.
>> Hope this makes sense.
>
>> > Shenandoah changes are not complete:
>> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp: In member function 'virtual
>> > void ShenandoahFinalMarkingTask::work(uint)':
>> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:298:31: error: 'oops_do' is
>> > not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&resolve_mark_cl); ^~~~~~~
>> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:308:31: error: 'oops_do' is
>> > not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&mark_cl);
>> > ^~~~~~~
>> > I will have a look into how to resolve this.
>> > In order to fix this, I need one of two things:
>> > ```
>> > * A way to iterate oops of the global-list. Explanation: In Shenandoah's I-U mode, we need to re-mark such ObjectMonitors
>> >   during final-mark because they may be the only remaining reference to an object on the heap.
>> >   _or_ (even better)
>> > 
>> > * Call a write-barrier (IN_NATIVE) whenever an ObjectMonitor is moved to the global-list upon thread-destruction. This
>> >   way we could mark that object concurrently.
>> > ```
>> > 
>> > 
>> > Notice that this does not affect thread-local ObjectMonitors (IOW, most regular ObjectMonitors) because those would be
>> > scanned while scanning thread stacks. Therefore I'd like to avoid to generally place a barrier in ObjectMonitor. See:
>> > https://bugs.openjdk.java.net/browse/JDK-8251451 AFAICT, this may affect ZGC too (not 100% sure about this).
>> 
>> So this change makes the object monitors weak. So you shouldn't have to remark them at all. If they hold the last
>> reference to the object, then the monitor gets the object cleared as part of normal weak OopStorage reference
>> processing. Subsequent deflation cycles will detect that the GC has cleared the oop, and reuse the monitor. In other
>> words, we should just remove the call to the oops_do function, and rely on OopStorage doing its thing. The GC should
>> not have to care at all about monitors any longer, only about processing weak OopStorages, which is done automatically.
>> Hope this makes sense.
> 
> Yes, definitely. I came to the same conclusion. Thank you!
> With the patch amended:
> http://cr.openjdk.java.net/~rkennke/8247281-shenandoah.patch
> 
> I'm good with the change.

@rkennke - I've commited the changes in your webrev as
https://github.com/openjdk/jdk/pull/135/commits/bbf8dbd09bdf5c1c77c67cc637fbc10fe72d4894.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 16:19:47 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 16:19:47 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v3]
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <K0Sk8LxOvpiGha7AFU2lhlsxQJohwsnhHU8Y8PoGoNM=.42ef7680-53b6-4ab2-b2e1-c6ccad0e0753@github.com>

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  rkennke CR - changes from Roman for Shenandoah.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/135/files
  - new: https://git.openjdk.java.net/jdk/pull/135/files/750fe771..bbf8dbd0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/135/head:pull/135

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 16:50:05 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 16:50:05 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW492Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
Message-ID: <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>

On Mon, 14 Sep 2020 16:16:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>>> > Shenandoah changes are not complete:
>>> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp: In member function 'virtual
>>> > void ShenandoahFinalMarkingTask::work(uint)':
>>> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:298:31: error: 'oops_do' is
>>> > not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&resolve_mark_cl); ^~~~~~~
>>> > /home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp:308:31: error: 'oops_do' is
>>> > not a member of 'ObjectSynchronizer' ObjectSynchronizer::oops_do(&mark_cl);
>>> > ^~~~~~~
>>> > I will have a look into how to resolve this.
>>> > In order to fix this, I need one of two things:
>>> > ```
>>> > * A way to iterate oops of the global-list. Explanation: In Shenandoah's I-U mode, we need to re-mark such ObjectMonitors
>>> >   during final-mark because they may be the only remaining reference to an object on the heap.
>>> >   _or_ (even better)
>>> > 
>>> > * Call a write-barrier (IN_NATIVE) whenever an ObjectMonitor is moved to the global-list upon thread-destruction. This
>>> >   way we could mark that object concurrently.
>>> > ```
>>> > 
>>> > 
>>> > Notice that this does not affect thread-local ObjectMonitors (IOW, most regular ObjectMonitors) because those would be
>>> > scanned while scanning thread stacks. Therefore I'd like to avoid to generally place a barrier in ObjectMonitor. See:
>>> > https://bugs.openjdk.java.net/browse/JDK-8251451 AFAICT, this may affect ZGC too (not 100% sure about this).
>>> 
>>> So this change makes the object monitors weak. So you shouldn't have to remark them at all. If they hold the last
>>> reference to the object, then the monitor gets the object cleared as part of normal weak OopStorage reference
>>> processing. Subsequent deflation cycles will detect that the GC has cleared the oop, and reuse the monitor. In other
>>> words, we should just remove the call to the oops_do function, and rely on OopStorage doing its thing. The GC should
>>> not have to care at all about monitors any longer, only about processing weak OopStorages, which is done automatically.
>>> Hope this makes sense.
>> 
>> Yes, definitely. I came to the same conclusion. Thank you!
>> With the patch amended:
>> http://cr.openjdk.java.net/~rkennke/8247281-shenandoah.patch
>> 
>> I'm good with the change.
>
> @rkennke - I've commited the changes in your webrev as
> https://github.com/openjdk/jdk/pull/135/commits/bbf8dbd09bdf5c1c77c67cc637fbc10fe72d4894.

@dholmes-ora and @fisk - I've taken a first pass at creating a CSR:
JDK-8253121 migrate ObjectMonitor::_object to OopStorage
https://bugs.openjdk.java.net/browse/JDK-8253121

Please look it over and feel free to edit as needed. Since I don't do
CSR's often, what I've done might be all wrong. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 17:13:08 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 17:13:08 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v3]
In-Reply-To: <K_Bz_OELObm82PGeA614-ZycobMJsTq4POIr-pTMFAQ=.7dbde28b-d00b-4462-a8b5-9a94fed3c839@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <FUxLEfUVidWZ2-LJlR4GoWIlAV61bDF-pyBSYl8fi98=.5c533df8-e93a-44ef-8620-ed90755b7030@github.com>
 <C3fEfvgPuX4VsbtUMiWOcy42-TsypfgEgL-Wefp8KC0=.9be2e223-6211-45b9-acb7-563f8067f8d6@github.com>
 <K_Bz_OELObm82PGeA614-ZycobMJsTq4POIr-pTMFAQ=.7dbde28b-d00b-4462-a8b5-9a94fed3c839@github.com>
Message-ID: <1rj4zO-L65NEG1ZyUdi3YyJR3A6AOTeb5cBsmVOiJ4E=.40e51e90-4008-46ea-a451-526144312035@github.com>

On Mon, 14 Sep 2020 01:52:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks for confirmation.
>
> I don't see anything in the HPROF format description that claims this is a strong root. At a minimum this seems to be a
> behavioural change that would warrant a CSR request. This also seems to be something that the serviceability folk
> should be made aware of and have a chance to comment on.

I've taken a first pass at creating a CSR:
JDK-8253121 migrate ObjectMonitor::_object to OopStorage
https://bugs.openjdk.java.net/browse/JDK-8253121

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 17:13:08 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 17:13:08 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v3]
In-Reply-To: <fIRORdoOh98JWKtHayhYzkIvG74kMAvQK5uMp3fiQFU=.280c4ce1-2ff1-4efe-9240-5335268e90e6@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <ExVVaITLKAVIH0GaprYE8g7xQ1GEAjChOAZGTGSO20o=.dc35b788-ffb7-40a6-850c-d80acc61ff9f@github.com>
 <fIRORdoOh98JWKtHayhYzkIvG74kMAvQK5uMp3fiQFU=.280c4ce1-2ff1-4efe-9240-5335268e90e6@github.com>
Message-ID: <absDZyL7vdcMv7BqG7u5eEdDJjLcJ2nkMkETt8gdPGg=.2aeaed15-8543-458b-b6b7-0560a5578b9a@github.com>

On Mon, 14 Sep 2020 02:00:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks for confirmation.
>
> From the spec I'm not clear on exactly what JVMTI_HEAP_REFERENCE_MONITOR is intended to be. Serviceability folk should
> be giving some input here though.

I've taken a first pass at creating a CSR:
JDK-8253121 migrate ObjectMonitor::_object to OopStorage
https://bugs.openjdk.java.net/browse/JDK-8253121

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 18:39:03 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 18:39:03 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
Message-ID: <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>

On Mon, 14 Sep 2020 18:33:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @dholmes-ora and @fisk - I've taken a first pass at creating a CSR:
>> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
>> https://bugs.openjdk.java.net/browse/JDK-8253121
>> 
>> Please look it over and feel free to edit as needed. Since I don't do
>> CSR's often, what I've done might be all wrong. :-)
>
> @kimbarrett:
> 
>> src/hotspot/share/oops/weakHandle.cpp
>> 36 WeakHandle::WeakHandle(OopStorage* storage, oop obj) :
>> 37 _obj(storage->allocate()) {
>> 38 assert(obj != NULL, "no need to create weak null oop");
>> 
>> Please format this differently so the ctor-init-list is more easily
>> distinguished from the body. I don't care that much which of the several
>> alternatives is used.
> 
> After discussion with Erik, I changed the indent on L37 from two space to four spaces.

@kimbarrett

> src/hotspot/share/runtime/objectMonitor.cpp
> 244 // Check that object() and set_object() are called from the right context:
> 245 static void check_object_context() {
> 
> This seems like checking we would normally only do in a debug build. Is this
> really supposed to be done in product builds too? (It's written to support
> that, just wondering if that's really what we want.) Maybe these aren't
> called very often so it doesn't matter? I also see that guarantee (rather
> than assert) is used a fair amount in this and related code.

I've changed check_object_context() to only be defined and called
when ASSERT is defined. I've also changed the guarantee() calls
to assert() calls.

I've done a couple of Mach5 Tier[1-8] test cycles on this code so I'm
no longer worried about this code or its callers in release bits.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 18:39:02 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 18:39:02 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
Message-ID: <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>

On Mon, 14 Sep 2020 16:47:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @rkennke - I've commited the changes in your webrev as
>> https://github.com/openjdk/jdk/pull/135/commits/bbf8dbd09bdf5c1c77c67cc637fbc10fe72d4894.
>
> @dholmes-ora and @fisk - I've taken a first pass at creating a CSR:
> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
> https://bugs.openjdk.java.net/browse/JDK-8253121
> 
> Please look it over and feel free to edit as needed. Since I don't do
> CSR's often, what I've done might be all wrong. :-)

@kimbarrett:

> src/hotspot/share/oops/weakHandle.cpp
> 36 WeakHandle::WeakHandle(OopStorage* storage, oop obj) :
> 37 _obj(storage->allocate()) {
> 38 assert(obj != NULL, "no need to create weak null oop");
> 
> Please format this differently so the ctor-init-list is more easily
> distinguished from the body. I don't care that much which of the several
> alternatives is used.

After discussion with Erik, I changed the indent on L37 from two space to four spaces.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 18:39:03 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 18:39:03 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
Message-ID: <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>

On Mon, 14 Sep 2020 18:35:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @kimbarrett:
>> 
>>> src/hotspot/share/oops/weakHandle.cpp
>>> 36 WeakHandle::WeakHandle(OopStorage* storage, oop obj) :
>>> 37 _obj(storage->allocate()) {
>>> 38 assert(obj != NULL, "no need to create weak null oop");
>>> 
>>> Please format this differently so the ctor-init-list is more easily
>>> distinguished from the body. I don't care that much which of the several
>>> alternatives is used.
>> 
>> After discussion with Erik, I changed the indent on L37 from two space to four spaces.
>
> @kimbarrett
> 
>> src/hotspot/share/runtime/objectMonitor.cpp
>> 244 // Check that object() and set_object() are called from the right context:
>> 245 static void check_object_context() {
>> 
>> This seems like checking we would normally only do in a debug build. Is this
>> really supposed to be done in product builds too? (It's written to support
>> that, just wondering if that's really what we want.) Maybe these aren't
>> called very often so it doesn't matter? I also see that guarantee (rather
>> than assert) is used a fair amount in this and related code.
> 
> I've changed check_object_context() to only be defined and called
> when ASSERT is defined. I've also changed the guarantee() calls
> to assert() calls.
> 
> I've done a couple of Mach5 Tier[1-8] test cycles on this code so I'm
> no longer worried about this code or its callers in release bits.

@kimbarrett

> src/hotspot/share/runtime/objectMonitor.cpp
> 249 guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
> 250 if (self->is_Java_thread()) {
> 
> Maybe instead
> 
> if (self->is_Java_thread()) {
> ...
> } else {
> guarantee(self->is_VM_thread(), "must be");
> }

I've made this refactoring change, tweaked the comments above
the block a bit and switched from guarantee() to assert().

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 18:42:33 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 18:42:33 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
 <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>
Message-ID: <YDTIqk9UC1YHNtO7nYjUkVEsJ2g3GEk-XweG0NEGshA=.38e2e216-29d8-4019-90b4-ac6582e71baf@github.com>

On Mon, 14 Sep 2020 18:36:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @kimbarrett
>> 
>>> src/hotspot/share/runtime/objectMonitor.cpp
>>> 244 // Check that object() and set_object() are called from the right context:
>>> 245 static void check_object_context() {
>>> 
>>> This seems like checking we would normally only do in a debug build. Is this
>>> really supposed to be done in product builds too? (It's written to support
>>> that, just wondering if that's really what we want.) Maybe these aren't
>>> called very often so it doesn't matter? I also see that guarantee (rather
>>> than assert) is used a fair amount in this and related code.
>> 
>> I've changed check_object_context() to only be defined and called
>> when ASSERT is defined. I've also changed the guarantee() calls
>> to assert() calls.
>> 
>> I've done a couple of Mach5 Tier[1-8] test cycles on this code so I'm
>> no longer worried about this code or its callers in release bits.
>
> @kimbarrett
> 
>> src/hotspot/share/runtime/objectMonitor.cpp
>> 249 guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
>> 250 if (self->is_Java_thread()) {
>> 
>> Maybe instead
>> 
>> if (self->is_Java_thread()) {
>> ...
>> } else {
>> guarantee(self->is_VM_thread(), "must be");
>> }
> 
> I've made this refactoring change, tweaked the comments above
> the block a bit and switched from guarantee() to assert().

@kimbarrett

> src/hotspot/share/runtime/synchronizer.cpp
> 1548 guarantee(m->object_peek() == NULL, "invariant");
> 
> Later: But see previous comment. Some of this might be relevat later though.
> 
> object_peek() seemed like the wrong operation here. I thought this was
> attempting to verify that the underlying WeakHandle has been released. But
> peeking doesn't ensure that. Oh, but we don't actually release() the
> WeakHandle when we "free" an OM. We're just pushing the OM on the free
> list. Which means the GC will continue to examine the associated OopStorage
> entry (and discover it's NULL). So there's some cost to not releasing the
> WeakHandle when putting an OM on the free list. Of course, it means there
> won't be any allocations when taking off the free list; I'm not sure which
> way is better.
> 
> But this makes me go back and wonder about whether object_peek() should have
> the _object.is_null() check. After creation it seems like that should never
> be true.

m->object_peek() == NULL is the right check at that location. om_release()
is called when we are returning an ObjectMonitor to a free list. At that point,
it should never be associated with an object.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 18:47:08 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 18:47:08 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <YDTIqk9UC1YHNtO7nYjUkVEsJ2g3GEk-XweG0NEGshA=.38e2e216-29d8-4019-90b4-ac6582e71baf@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
 <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>
 <YDTIqk9UC1YHNtO7nYjUkVEsJ2g3GEk-XweG0NEGshA=.38e2e216-29d8-4019-90b4-ac6582e71baf@github.com>
Message-ID: <6C-kpuZszd3T_WGL0HbPq70g9QiqEzs2fQ2v71FC2T4=.64508cfd-0baf-48e7-a829-b2ddb7c52c66@github.com>

On Mon, 14 Sep 2020 18:39:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @kimbarrett
>> 
>>> src/hotspot/share/runtime/objectMonitor.cpp
>>> 249 guarantee(self->is_Java_thread() || self->is_VM_thread(), "must be");
>>> 250 if (self->is_Java_thread()) {
>>> 
>>> Maybe instead
>>> 
>>> if (self->is_Java_thread()) {
>>> ...
>>> } else {
>>> guarantee(self->is_VM_thread(), "must be");
>>> }
>> 
>> I've made this refactoring change, tweaked the comments above
>> the block a bit and switched from guarantee() to assert().
>
> @kimbarrett
> 
>> src/hotspot/share/runtime/synchronizer.cpp
>> 1548 guarantee(m->object_peek() == NULL, "invariant");
>> 
>> Later: But see previous comment. Some of this might be relevat later though.
>> 
>> object_peek() seemed like the wrong operation here. I thought this was
>> attempting to verify that the underlying WeakHandle has been released. But
>> peeking doesn't ensure that. Oh, but we don't actually release() the
>> WeakHandle when we "free" an OM. We're just pushing the OM on the free
>> list. Which means the GC will continue to examine the associated OopStorage
>> entry (and discover it's NULL). So there's some cost to not releasing the
>> WeakHandle when putting an OM on the free list. Of course, it means there
>> won't be any allocations when taking off the free list; I'm not sure which
>> way is better.
>> 
>> But this makes me go back and wonder about whether object_peek() should have
>> the _object.is_null() check. After creation it seems like that should never
>> be true.
> 
> m->object_peek() == NULL is the right check at that location. om_release()
> is called when we are returning an ObjectMonitor to a free list. At that point,
> it should never be associated with an object.

@kimbarrett

> src/hotspot/share/runtime/synchronizer.cpp
> 
> The old code in chk_in_use_entry seems wrong. It checked for a null
> object() and recorded that as an error. But then it went on and attempted
> to use it as if it was not null. That's been fixed by the change. However,
> the change no longer treats a null as an error. Probably this is because
> it's weak, and so could have become null. But is that really possible for
> an "in use" monitor?

In the old code, an ObjectMonitor's object field should never be NULL when
that ObjectMonitor is on an in-use list. We'll get the logging message and
then a crash. I used to have guarantee(n->object() != NULL, ...) in there,
but Robbin convinced me that was a waste because we'll just crash on
the use of the NULL pointer and that was good enough.

As Erik has already explained, now that we use a weak handle, the object
can be GC'ed before the deflater thread comes along and removes the
idle ObjectMonitor from the in-use list.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 18:55:38 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 18:55:38 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <6C-kpuZszd3T_WGL0HbPq70g9QiqEzs2fQ2v71FC2T4=.64508cfd-0baf-48e7-a829-b2ddb7c52c66@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
 <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>
 <YDTIqk9UC1YHNtO7nYjUkVEsJ2g3GEk-XweG0NEGshA=.38e2e216-29d8-4019-90b4-ac6582e71baf@github.com>
 <6C-kpuZszd3T_WGL0HbPq70g9QiqEzs2fQ2v71FC2T4=.64508cfd-0baf-48e7-a829-b2ddb7c52c66@github.com>
Message-ID: <WZB0eOGXLgTDm-5Z099v0jHC4DOnstfmIDlkqM8XlNg=.c0c2c362-dc00-47b3-b696-d4e4d3fb3299@github.com>

On Mon, 14 Sep 2020 18:44:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @kimbarrett
>> 
>>> src/hotspot/share/runtime/synchronizer.cpp
>>> 1548 guarantee(m->object_peek() == NULL, "invariant");
>>> 
>>> Later: But see previous comment. Some of this might be relevat later though.
>>> 
>>> object_peek() seemed like the wrong operation here. I thought this was
>>> attempting to verify that the underlying WeakHandle has been released. But
>>> peeking doesn't ensure that. Oh, but we don't actually release() the
>>> WeakHandle when we "free" an OM. We're just pushing the OM on the free
>>> list. Which means the GC will continue to examine the associated OopStorage
>>> entry (and discover it's NULL). So there's some cost to not releasing the
>>> WeakHandle when putting an OM on the free list. Of course, it means there
>>> won't be any allocations when taking off the free list; I'm not sure which
>>> way is better.
>>> 
>>> But this makes me go back and wonder about whether object_peek() should have
>>> the _object.is_null() check. After creation it seems like that should never
>>> be true.
>> 
>> m->object_peek() == NULL is the right check at that location. om_release()
>> is called when we are returning an ObjectMonitor to a free list. At that point,
>> it should never be associated with an object.
>
> @kimbarrett
> 
>> src/hotspot/share/runtime/synchronizer.cpp
>> 
>> The old code in chk_in_use_entry seems wrong. It checked for a null
>> object() and recorded that as an error. But then it went on and attempted
>> to use it as if it was not null. That's been fixed by the change. However,
>> the change no longer treats a null as an error. Probably this is because
>> it's weak, and so could have become null. But is that really possible for
>> an "in use" monitor?
> 
> In the old code, an ObjectMonitor's object field should never be NULL when
> that ObjectMonitor is on an in-use list. We'll get the logging message and
> then a crash. I used to have guarantee(n->object() != NULL, ...) in there,
> but Robbin convinced me that was a waste because we'll just crash on
> the use of the NULL pointer and that was good enough.
> 
> As Erik has already explained, now that we use a weak handle, the object
> can be GC'ed before the deflater thread comes along and removes the
> idle ObjectMonitor from the in-use list.

@kimbarrett - I believe I've addressed your comments in this push:
https://github.com/openjdk/jdk/pull/135/commits/9fa2bed109d6fe352c610b26ada650226ce9cec4

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 18:55:38 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 18:55:38 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  kimbarrett CR - made minor changes to address Kim's code review.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/135/files
  - new: https://git.openjdk.java.net/jdk/pull/135/files/bbf8dbd0..9fa2bed1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=02-03

  Stats: 16 lines in 2 files changed: 11 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/135/head:pull/135

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 19:02:17 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 19:02:17 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <WZB0eOGXLgTDm-5Z099v0jHC4DOnstfmIDlkqM8XlNg=.c0c2c362-dc00-47b3-b696-d4e4d3fb3299@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
 <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>
 <YDTIqk9UC1YHNtO7nYjUkVEsJ2g3GEk-XweG0NEGshA=.38e2e216-29d8-4019-90b4-ac6582e71baf@github.com>
 <6C-kpuZszd3T_WGL0HbPq70g9QiqEzs2fQ2v71FC2T4=.64508cfd-0baf-48e7-a829-b2ddb7c52c66@github.com>
 <WZB0eOGXLgTDm-5Z099v0jHC4DOnstfmIDlkqM8XlNg=.c0c2c362-dc00-47b3-b696-d4e4d3fb3299@github.com>
Message-ID: <gB8QqLIpa-_MXrCJKRdciE2bqhLRMRp0sM4SIwPVpfI=.a9c8c548-240f-4dbd-b65e-107efb5eb5c4@github.com>

On Mon, 14 Sep 2020 18:51:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @kimbarrett
>> 
>>> src/hotspot/share/runtime/synchronizer.cpp
>>> 
>>> The old code in chk_in_use_entry seems wrong. It checked for a null
>>> object() and recorded that as an error. But then it went on and attempted
>>> to use it as if it was not null. That's been fixed by the change. However,
>>> the change no longer treats a null as an error. Probably this is because
>>> it's weak, and so could have become null. But is that really possible for
>>> an "in use" monitor?
>> 
>> In the old code, an ObjectMonitor's object field should never be NULL when
>> that ObjectMonitor is on an in-use list. We'll get the logging message and
>> then a crash. I used to have guarantee(n->object() != NULL, ...) in there,
>> but Robbin convinced me that was a waste because we'll just crash on
>> the use of the NULL pointer and that was good enough.
>> 
>> As Erik has already explained, now that we use a weak handle, the object
>> can be GC'ed before the deflater thread comes along and removes the
>> idle ObjectMonitor from the in-use list.
>
> @kimbarrett - I believe I've addressed your comments in this push:
> https://github.com/openjdk/jdk/pull/135/commits/9fa2bed109d6fe352c610b26ada650226ce9cec4

@coleenp, @rkennke, and @kimbarrett - I believe all of the changes that you have requested
have been made. Please confirm by re-reviewing.

@dholmes-ora - I don't think you asked for any specific code changes. I've taken a first pass
at creating a CSR:
JDK-8253121 migrate ObjectMonitor::_object to OopStorage
https://bugs.openjdk.java.net/browse/JDK-8253121

Please look it over and feel free to edit as needed. Since I don't do
CSR's often, what I've done might be all wrong. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From kim.barrett at oracle.com  Mon Sep 14 19:29:47 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 14 Sep 2020 15:29:47 -0400
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
Message-ID: <D3C18C1B-BB1E-4899-A91F-63E93176371B@oracle.com>

> On Sep 14, 2020, at 2:39 PM, Daniel D.Daugherty <dcubed at openjdk.java.net> wrote:
> 
> On Mon, 14 Sep 2020 18:33:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
> 
>> @kimbarrett:
>> 
>>> src/hotspot/share/oops/weakHandle.cpp
>>> 36 WeakHandle::WeakHandle(OopStorage* storage, oop obj) :
>>> 37 _obj(storage->allocate()) {
>>> 38 assert(obj != NULL, "no need to create weak null oop");
>>> 
>>> Please format this differently so the ctor-init-list is more easily
>>> distinguished from the body. I don't care that much which of the several
>>> alternatives is used.
>> 
>> After discussion with Erik, I changed the indent on L37 from two space to four spaces.
> 
> @kimbarrett

Thanks.  That?s one of the ?several alternatives? I was alluding to.


From rkennke at openjdk.java.net  Mon Sep 14 20:07:53 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 14 Sep 2020 20:07:53 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <gB8QqLIpa-_MXrCJKRdciE2bqhLRMRp0sM4SIwPVpfI=.a9c8c548-240f-4dbd-b65e-107efb5eb5c4@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
 <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>
 <YDTIqk9UC1YHNtO7nYjUkVEsJ2g3GEk-XweG0NEGshA=.38e2e216-29d8-4019-90b4-ac6582e71baf@github.com>
 <6C-kpuZszd3T_WGL0HbPq70g9QiqEzs2fQ2v71FC2T4=.64508cfd-0baf-48e7-a829-b2ddb7c52c66@github.com>
 <WZB0eOGXLgTDm-5Z099v0jHC4DOnstfmIDlkqM8XlNg=.c0c2c362-dc00-47b3-b696-d4e4d3fb3299@github.com>
 <gB8QqLIpa-_MXrCJKRdciE2bqhLRMRp0sM4SIwPVpfI=.a9c8c548-240f-4dbd-b65e-107efb5eb5c4@github.com>
Message-ID: <sqJvgXKliDWVCrmj-YyL7O6xhrzHPD2mVlXCmiHhd5s=.a8ac7a05-6a20-4fcc-9daa-d886b06b9011@github.com>

On Mon, 14 Sep 2020 18:59:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> @coleenp, @rkennke, and @kimbarrett - I believe all of the changes that you have requested
> have been made. Please confirm by re-reviewing.

It looks good to me now! I've also build with Shenandoah GC, and run our sanity-tests (TEST=hotspot_gc_shenandoah) and
all looks good. Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From rkennke at openjdk.java.net  Mon Sep 14 20:18:38 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 14 Sep 2020 20:18:38 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
Message-ID: <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>

On Mon, 14 Sep 2020 18:55:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett CR - made minor changes to address Kim's code review.

src/hotspot/share/gc/shared/space.inline.hpp line 176:

> 174:       assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
> 175:              oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
> 176:              "these are the only valid states during a mark sweep");

Is this change related? Also, when moving the assert into the else block it will become always-true because of
space->scanned_block_is_obj(cur_obj), or am I missing something?

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 20:24:12 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 20:24:12 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
Message-ID: <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>

On Mon, 14 Sep 2020 20:10:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kimbarrett CR - made minor changes to address Kim's code review.
>
> src/hotspot/share/gc/shared/space.inline.hpp line 176:
> 
>> 174:       assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
>> 175:              oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
>> 176:              "these are the only valid states during a mark sweep");
> 
> Is this change related? Also, when moving the assert into the else block it will become always-true because of
> space->scanned_block_is_obj(cur_obj), or am I missing something?

See this comment from Coleen and the replies:
https://github.com/openjdk/jdk/pull/135#discussion_r487300636

Please let me know if that resolved this comment for you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 20:24:11 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 20:24:11 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v2]
In-Reply-To: <sqJvgXKliDWVCrmj-YyL7O6xhrzHPD2mVlXCmiHhd5s=.a8ac7a05-6a20-4fcc-9daa-d886b06b9011@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uuFF7rOQoWMfttmjaSJB38AG1A7YUVtDxuT3I5XDSQU=.2178be72-a86a-4fc4-83c8-40653e242b74@github.com>
 <3Br1W5wlBiJiBpIMA8Pm7HaLB0nFBNAUyoGYoJb4lc0=.20b26eea-5157-45c2-9a43-76ed9b554514@github.com>
 <RRLGk15_vDlKi5KqZ9BS3s36RtvYDAvwupZAItoCW_M=.062143bc-c3ba-4845-9358-be9b052e1dd9@github.com>
 <Vq9-HR1wVCiPFneaOBV50nvg6qqeqVvFqTQT1PkehVE=.446370d0-4974-4dfb-8ac1-fb9a789cfb48@github.com>
 <B_QfleUWzhE17J3pCKB4mKHiO6KNBOoa7cO8c6-tUYo=.816103a8-365c-49c1-8926-187d3bddf360@github.com>
 <SJIu2fP1CCnx4JmfOCD9vBuI7zsTOj8_sjaTz3MyUxY=.56ddc9fb-4acf-40c2-a26d-b265626abb39@github.com>
 <rpK-0ZzvxSbkEWvkUdA57KHvmqQZD74r9mnwuGvD4uo=.a3b4f352-bd35-44f7-92b9-ecd020e59a34@github.com>
 <sNkdVc4rGXDDKQg39Ry2H4FJCXcl1SXevNrhZZnEsb4=.c1f542a4-434a-4ee5-9666-158fa18564d2@github.com>
 <5ktowf9ho39sRCq22E56krjEeTmOLzagSyR9UULnJNs=.acf484c6-c6d2-440b-acc4-52e12750c52e@github.com>
 <MbmzVUGFtWhczASggJznvXYx5HfHp6-wW49
 2Y2_SFZY=.e3351f10-a730-48ee-aaaf-760c73502039@github.com>
 <qu4irXBw35H__t6xXhQMsuuCVHt1i2rnbM-GIuh5EnA=.4a723f5a-addc-4e5a-a317-4b87e1ba6ae2@github.com>
 <74w2VsorZYr6qJxvXN5yM1o6Dw1J0bzeEihOmV_eHCs=.dd020fbd-1f1a-469c-b9d7-dbc313770d66@github.com>
 <ZvLV2R1eIBuqBVmwLsgiLDZMlElGD34Nhl_BQrNSm9w=.7b57c9d2-a560-41a8-aff3-e73b8236f9cb@github.com>
 <Tct3KUGZ3pXLvln2OVszj2Es15Um_EjDg2QsIWoBZio=.3b743d27-86f3-4c56-b944-ce3abb573588@github.com>
 <YDTIqk9UC1YHNtO7nYjUkVEsJ2g3GEk-XweG0NEGshA=.38e2e216-29d8-4019-90b4-ac6582e71baf@github.com>
 <6C-kpuZszd3T_WGL0HbPq70g9QiqEzs2fQ2v71FC2T4=.64508cfd-0baf-48e7-a829-b2ddb7c52c66@github.com>
 <WZB0eOGXLgTDm-5Z099v0jHC4DOnstfmIDlkqM8XlNg=.c0c2c362-dc00-47b3-b696-d4e4d3fb3299@github.com>
 <gB8QqLIpa-_MXrCJKRdciE2bqhLRMRp0sM4SIwPVpfI=.a9c8c548-240f-4dbd-b65e-107efb5eb5c4@github.com>
 <sqJvgXKliDWVCrmj-YyL7O6xhrzHPD2mVlXCmiHhd5s=.a8ac7a05-6a20-4fcc-9daa-d886b06b9011@github.com>
Message-ID: <9hEXk57qPOk4VvO3fuTowg2Z_Xuw3WCnnW8xaZvLpFU=.50a740a7-fd65-42ca-ba06-ba1e76922ba1@github.com>

On Mon, 14 Sep 2020 20:05:06 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> @coleenp, @rkennke, and @kimbarrett - I believe all of the changes that you have requested
>> have been made. Please confirm by re-reviewing.
>> 
>> @dholmes-ora - I don't think you asked for any specific code changes. I've taken a first pass
>> at creating a CSR:
>> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
>> https://bugs.openjdk.java.net/browse/JDK-8253121
>> 
>> Please look it over and feel free to edit as needed. Since I don't do
>> CSR's often, what I've done might be all wrong. :-)
>
>> @coleenp, @rkennke, and @kimbarrett - I believe all of the changes that you have requested
>> have been made. Please confirm by re-reviewing.
> 
> It looks good to me now! I've also build with Shenandoah GC, and run our sanity-tests (TEST=hotspot_gc_shenandoah) and
> all looks good. Thank you!

@rkennke - Thanks for confirming that Shenandoah now builds with the changes
that you provided. Thanks for sending those.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From rkennke at openjdk.java.net  Mon Sep 14 20:28:30 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 14 Sep 2020 20:28:30 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
Message-ID: <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>

On Mon, 14 Sep 2020 20:21:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/space.inline.hpp line 176:
>> 
>>> 174:       assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
>>> 175:              oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
>>> 176:              "these are the only valid states during a mark sweep");
>> 
>> Is this change related? Also, when moving the assert into the else block it will become always-true because of
>> space->scanned_block_is_obj(cur_obj), or am I missing something?
>
> See this comment from Coleen and the replies:
> https://github.com/openjdk/jdk/pull/135#discussion_r487300636
> 
> Please let me know if that resolved this comment for you.

Sorry, no. Maybe it's too late here and I shall think about it tomorrow morning instead ;-) Or maybe you can explain it
again in the context of that change. How's the assert even relevant when moved in the else-branch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 20:36:42 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 20:36:42 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
Message-ID: <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>

On Mon, 14 Sep 2020 20:25:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See this comment from Coleen and the replies:
>> https://github.com/openjdk/jdk/pull/135#discussion_r487300636
>> 
>> Please let me know if that resolved this comment for you.
>
> Sorry, no. Maybe it's too late here and I shall think about it tomorrow morning instead ;-) Or maybe you can explain it
> again in the context of that change. How's the assert even relevant when moved in the else-branch?

Sorry, I confused myself switching between this review and a
preliminary review thread.

Here's the original code:

165   while (cur_obj < scan_limit) {
166     assert(!space->scanned_block_is_obj(cur_obj) ||
167            oop(cur_obj)->mark_raw().is_marked() || oop(cur_obj)->mark_raw().is_unlocked() ||
168            oop(cur_obj)->mark_raw().has_bias_pattern(),
169            "these are the only valid states during a mark sweep");
170     if (space->scanned_block_is_obj(cur_obj) && oop(cur_obj)->is_gc_marked()) {

and here's the code after it was moved and rewritten:

173     } else {
174       assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
175              oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
176              "these are the only valid states during a mark sweep");


Where the assert() was worked fine when the ObjectMonitor had a regular oop,
but after it was changed into a weak handle, that location became exposed to
the fact that the object reference could be GC'ed. The original code assumes
that the ObjectMonitor oop reference is stable and unchanging and that's no
longer the case with the weak handle.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 20:51:06 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 20:51:06 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
 <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
Message-ID: <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>

On Mon, 14 Sep 2020 20:34:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Sorry, no. Maybe it's too late here and I shall think about it tomorrow morning instead ;-) Or maybe you can explain it
>> again in the context of that change. How's the assert even relevant when moved in the else-branch?
>
> Sorry, I confused myself switching between this review and a
> preliminary review thread.
> 
> Here's the original code:
> 
> 165   while (cur_obj < scan_limit) {
> 166     assert(!space->scanned_block_is_obj(cur_obj) ||
> 167            oop(cur_obj)->mark_raw().is_marked() || oop(cur_obj)->mark_raw().is_unlocked() ||
> 168            oop(cur_obj)->mark_raw().has_bias_pattern(),
> 169            "these are the only valid states during a mark sweep");
> 170     if (space->scanned_block_is_obj(cur_obj) && oop(cur_obj)->is_gc_marked()) {
> 
> and here's the code after it was moved and rewritten:
> 
> 173     } else {
> 174       assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
> 175              oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
> 176              "these are the only valid states during a mark sweep");
> 
> 
> Where the assert() was worked fine when the ObjectMonitor had a regular oop,
> but after it was changed into a weak handle, that location became exposed to
> the fact that the object reference could be GC'ed. The original code assumes
> that the ObjectMonitor oop reference is stable and unchanging and that's no
> longer the case with the weak handle.

I found my original preliminary code review comment and Erik's reply:

> src/hotspot/share/gc/shared/space.inline.hpp
>     old L166:     assert(!space->scanned_block_is_obj(cur_obj) ||
>     old L167:            oop(cur_obj)->mark_raw().is_marked() || oop(cur_obj)->mark_raw().is_unlocked() ||
>     old L168: oop(cur_obj)->mark_raw().has_bias_pattern(),
>     old L169:            "these are the only valid states during a mark sweep");
>         This assert was before the if-statement at the top of the while-loop.
>
>     new L174: assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
>     new L175: oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
>     new L176:              "these are the only valid states during a mark sweep");
>         The assert is now in the else branch of the following if-statement:
>
>            L166     if (space->scanned_block_is_obj(cur_obj) && oop(cur_obj)->is_gc_marked()) {
>
>         The new assert() drops this check:
>
>             oop(cur_obj)->mark_raw().is_marked()
>
>         and adds this check:
>
>             oop(cur_obj)->mark_raw().has_monitor()
>
>         Dropping the "is_marked()" makes sense since the new location
>         of the assert is in the else branch of "oop(cur_obj)->is_gc_marked()".
>         The addition of the "has_monitor()" check is puzzling. Why was this
>         added and why wasn't it needed in the old assert()?
>
>         In fact, I'm not sure why this change is here at all.

This is an artifact of the monitor now being weak. Since there was previously always a strong root
to all inflated monitors, there were never any dead objects in the heap, that still had pointers in the
mark word to the monitor. The change to weak now implies that we suddenly have dead objects
in the heap, that in the markWord point out their monitor. GC code that iterates through consecutive
objects one by one, will see these now dead objects with monitors. The assert changes reflect that.
Before it was unexpected and would assert on that. Now I moved the assertion to the case when the
object is alive instead. We have no business asserting what should be in the markWord of dead objects.

I hope it makes sense now!

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From coleenp at openjdk.java.net  Mon Sep 14 20:51:06 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 14 Sep 2020 20:51:06 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
 <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
 <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>
Message-ID: <yXBIskeCE5U-O3jc6jSwsYczdSGanoaMSXb6EazbXyE=.ad5c5334-07e9-4edb-9743-ffbe554a5cba@github.com>

On Mon, 14 Sep 2020 20:45:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Sorry, I confused myself switching between this review and a
>> preliminary review thread.
>> 
>> Here's the original code:
>> 
>> 165   while (cur_obj < scan_limit) {
>> 166     assert(!space->scanned_block_is_obj(cur_obj) ||
>> 167            oop(cur_obj)->mark_raw().is_marked() || oop(cur_obj)->mark_raw().is_unlocked() ||
>> 168            oop(cur_obj)->mark_raw().has_bias_pattern(),
>> 169            "these are the only valid states during a mark sweep");
>> 170     if (space->scanned_block_is_obj(cur_obj) && oop(cur_obj)->is_gc_marked()) {
>> 
>> and here's the code after it was moved and rewritten:
>> 
>> 173     } else {
>> 174       assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
>> 175              oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
>> 176              "these are the only valid states during a mark sweep");
>> 
>> 
>> Where the assert() was worked fine when the ObjectMonitor had a regular oop,
>> but after it was changed into a weak handle, that location became exposed to
>> the fact that the object reference could be GC'ed. The original code assumes
>> that the ObjectMonitor oop reference is stable and unchanging and that's no
>> longer the case with the weak handle.
>
> I found my original preliminary code review comment and Erik's reply:
> 
>> src/hotspot/share/gc/shared/space.inline.hpp
>>     old L166:     assert(!space->scanned_block_is_obj(cur_obj) ||
>>     old L167:            oop(cur_obj)->mark_raw().is_marked() || oop(cur_obj)->mark_raw().is_unlocked() ||
>>     old L168: oop(cur_obj)->mark_raw().has_bias_pattern(),
>>     old L169:            "these are the only valid states during a mark sweep");
>>         This assert was before the if-statement at the top of the while-loop.
>>
>>     new L174: assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
>>     new L175: oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
>>     new L176:              "these are the only valid states during a mark sweep");
>>         The assert is now in the else branch of the following if-statement:
>>
>>            L166     if (space->scanned_block_is_obj(cur_obj) && oop(cur_obj)->is_gc_marked()) {
>>
>>         The new assert() drops this check:
>>
>>             oop(cur_obj)->mark_raw().is_marked()
>>
>>         and adds this check:
>>
>>             oop(cur_obj)->mark_raw().has_monitor()
>>
>>         Dropping the "is_marked()" makes sense since the new location
>>         of the assert is in the else branch of "oop(cur_obj)->is_gc_marked()".
>>         The addition of the "has_monitor()" check is puzzling. Why was this
>>         added and why wasn't it needed in the old assert()?
>>
>>         In fact, I'm not sure why this change is here at all.
> 
> This is an artifact of the monitor now being weak. Since there was previously always a strong root
> to all inflated monitors, there were never any dead objects in the heap, that still had pointers in the
> mark word to the monitor. The change to weak now implies that we suddenly have dead objects
> in the heap, that in the markWord point out their monitor. GC code that iterates through consecutive
> objects one by one, will see these now dead objects with monitors. The assert changes reflect that.
> Before it was unexpected and would assert on that. Now I moved the assertion to the case when the
> object is alive instead. We have no business asserting what should be in the markWord of dead objects.
> 
> I hope it makes sense now!

This code seems like something that doesn't belong here anymore.  This code assumed synchronous scanning of oops in
ObjectMonitor and scanning memory regions, and that's no longer the case with OopStorage. I think this assert should be
removed.  It exports some implementation detail of now completely unrelated code in order to do a very specific check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 20:54:14 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 20:54:14 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <yXBIskeCE5U-O3jc6jSwsYczdSGanoaMSXb6EazbXyE=.ad5c5334-07e9-4edb-9743-ffbe554a5cba@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
 <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
 <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>
 <yXBIskeCE5U-O3jc6jSwsYczdSGanoaMSXb6EazbXyE=.ad5c5334-07e9-4edb-9743-ffbe554a5cba@github.com>
Message-ID: <9_5byOZc3b5-zKH7LFe12s2OKdp6RQ_k4Iq1hZTp32g=.482bd52f-19d0-4d02-b318-f455570a897a@github.com>

On Mon, 14 Sep 2020 20:48:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I found my original preliminary code review comment and Erik's reply:
>> 
>>> src/hotspot/share/gc/shared/space.inline.hpp
>>>     old L166:     assert(!space->scanned_block_is_obj(cur_obj) ||
>>>     old L167:            oop(cur_obj)->mark_raw().is_marked() || oop(cur_obj)->mark_raw().is_unlocked() ||
>>>     old L168: oop(cur_obj)->mark_raw().has_bias_pattern(),
>>>     old L169:            "these are the only valid states during a mark sweep");
>>>         This assert was before the if-statement at the top of the while-loop.
>>>
>>>     new L174: assert(!space->scanned_block_is_obj(cur_obj) || oop(cur_obj)->mark_raw().is_unlocked() ||
>>>     new L175: oop(cur_obj)->mark_raw().has_bias_pattern() || oop(cur_obj)->mark_raw().has_monitor(),
>>>     new L176:              "these are the only valid states during a mark sweep");
>>>         The assert is now in the else branch of the following if-statement:
>>>
>>>            L166     if (space->scanned_block_is_obj(cur_obj) && oop(cur_obj)->is_gc_marked()) {
>>>
>>>         The new assert() drops this check:
>>>
>>>             oop(cur_obj)->mark_raw().is_marked()
>>>
>>>         and adds this check:
>>>
>>>             oop(cur_obj)->mark_raw().has_monitor()
>>>
>>>         Dropping the "is_marked()" makes sense since the new location
>>>         of the assert is in the else branch of "oop(cur_obj)->is_gc_marked()".
>>>         The addition of the "has_monitor()" check is puzzling. Why was this
>>>         added and why wasn't it needed in the old assert()?
>>>
>>>         In fact, I'm not sure why this change is here at all.
>> 
>> This is an artifact of the monitor now being weak. Since there was previously always a strong root
>> to all inflated monitors, there were never any dead objects in the heap, that still had pointers in the
>> mark word to the monitor. The change to weak now implies that we suddenly have dead objects
>> in the heap, that in the markWord point out their monitor. GC code that iterates through consecutive
>> objects one by one, will see these now dead objects with monitors. The assert changes reflect that.
>> Before it was unexpected and would assert on that. Now I moved the assertion to the case when the
>> object is alive instead. We have no business asserting what should be in the markWord of dead objects.
>> 
>> I hope it makes sense now!
>
> This code seems like something that doesn't belong here anymore.  This code assumed synchronous scanning of oops in
> ObjectMonitor and scanning memory regions, and that's no longer the case with OopStorage. I think this assert should be
> removed.  It exports some implementation detail of now completely unrelated code in order to do a very specific check.

@fisk - please chime in here...

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From rkennke at openjdk.java.net  Mon Sep 14 20:54:14 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 14 Sep 2020 20:54:14 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <9_5byOZc3b5-zKH7LFe12s2OKdp6RQ_k4Iq1hZTp32g=.482bd52f-19d0-4d02-b318-f455570a897a@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
 <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
 <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>
 <yXBIskeCE5U-O3jc6jSwsYczdSGanoaMSXb6EazbXyE=.ad5c5334-07e9-4edb-9743-ffbe554a5cba@github.com>
 <9_5byOZc3b5-zKH7LFe12s2OKdp6RQ_k4Iq1hZTp32g=.482bd52f-19d0-4d02-b318-f455570a897a@github.com>
Message-ID: <Lrfc3wDRxopyuKdf53irwa88m-IPrH0Y7f59Zo2yhmY=.0f0d2eed-431b-4aca-826d-ee1b31cb004e@github.com>

On Mon, 14 Sep 2020 20:51:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This code seems like something that doesn't belong here anymore.  This code assumed synchronous scanning of oops in
>> ObjectMonitor and scanning memory regions, and that's no longer the case with OopStorage. I think this assert should be
>> removed.  It exports some implementation detail of now completely unrelated code in order to do a very specific check.
>
> @fisk - please chime in here...

I agree. Also, the assert becomes true somewhat obviously because of its first clause, which is already guaranteed
because of its placement in the surrounding else-branch (unless something really weird happens).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Mon Sep 14 21:05:31 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 14 Sep 2020 21:05:31 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <Lrfc3wDRxopyuKdf53irwa88m-IPrH0Y7f59Zo2yhmY=.0f0d2eed-431b-4aca-826d-ee1b31cb004e@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
 <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
 <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>
 <yXBIskeCE5U-O3jc6jSwsYczdSGanoaMSXb6EazbXyE=.ad5c5334-07e9-4edb-9743-ffbe554a5cba@github.com>
 <9_5byOZc3b5-zKH7LFe12s2OKdp6RQ_k4Iq1hZTp32g=.482bd52f-19d0-4d02-b318-f455570a897a@github.com>
 <Lrfc3wDRxopyuKdf53irwa88m-IPrH0Y7f59Zo2yhmY=.0f0d2eed-431b-4aca-826d-ee1b31cb004e@github.com>
Message-ID: <OEMH8UN24jWqBcC6EItenNGlc-tsH1wIk_v79bBcVuk=.9ce8d383-484f-45bd-98d3-6f3430345ea8@github.com>

On Mon, 14 Sep 2020 20:51:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> @fisk - please chime in here...
>
> I agree. Also, the assert becomes true somewhat obviously because of its first clause, which is already guaranteed
> because of its placement in the surrounding else-branch (unless something really weird happens).

I am also 100% okay with just removing the random assertion. We have a whole bunch of other block iteration code in GC
code that does not sprinkle random asserts about what patterns of markWords are supposedly good or bad in live/dead
objects. And I also don't get what kind of bug this would catch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 21:09:57 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 21:09:57 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <OEMH8UN24jWqBcC6EItenNGlc-tsH1wIk_v79bBcVuk=.9ce8d383-484f-45bd-98d3-6f3430345ea8@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
 <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
 <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>
 <yXBIskeCE5U-O3jc6jSwsYczdSGanoaMSXb6EazbXyE=.ad5c5334-07e9-4edb-9743-ffbe554a5cba@github.com>
 <9_5byOZc3b5-zKH7LFe12s2OKdp6RQ_k4Iq1hZTp32g=.482bd52f-19d0-4d02-b318-f455570a897a@github.com>
 <Lrfc3wDRxopyuKdf53irwa88m-IPrH0Y7f59Zo2yhmY=.0f0d2eed-431b-4aca-826d-ee1b31cb004e@github.com>
 <OEMH8UN24jWqBcC6EItenNGlc-tsH1wIk_v
 79bBcVuk=.9ce8d383-484f-45bd-98d3-6f3430345ea8@github.com>
Message-ID: <LUmB4qJuitWI8hHgzNe85teVtzW-w5tR41GtCgzPtE4=.045fed4e-78be-42ab-8055-5c3698767028@github.com>

On Mon, 14 Sep 2020 21:02:51 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> I agree. Also, the assert becomes true somewhat obviously because of its first clause, which is already guaranteed
>> because of its placement in the surrounding else-branch (unless something really weird happens).
>
> I am also 100% okay with just removing the random assertion. We have a whole bunch of other block iteration code in GC
> code that does not sprinkle random asserts about what patterns of markWords are supposedly good or bad in live/dead
> objects. And I also don't get what kind of bug this would catch.

Okay. Since @coleenp, @rkennke and @fisk want that assertion to "hit the road",
I'm in the process of removing it... build running now (just 'cause I'm paranoid me...)...

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 21:15:00 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 21:15:00 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <LUmB4qJuitWI8hHgzNe85teVtzW-w5tR41GtCgzPtE4=.045fed4e-78be-42ab-8055-5c3698767028@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <LhqswJgHGBKhOHapUXMrCylXRhkeX7HwoDbu-_xqhdQ=.64eb0c1e-572e-4f7d-8685-740b1105d93f@github.com>
 <k8bk9XZgeWMZ8xOBqGqsFDi5H3qQ6vkBUvFw6BBvuUk=.5c300ada-fb62-4bee-84c4-847dd82d298f@github.com>
 <yiTM6dly0pnzl9E0eSThoY-o5TSohChzroToJ57HWbc=.8e92549a-485e-4a96-9b62-cdd1907d5bda@github.com>
 <myndlGrTt2B4EQZpOUIclOJsdTAhZdioyiGhqQRDb3I=.b9ec6aeb-4093-4b9e-bbb5-8d030ccbb4ea@github.com>
 <7S-JQve0hEaKd5B_ryBa1tnTyIYdr4jJvMWdbJCVACM=.ea27fbfc-89e8-4b9f-b99e-fdae0d579718@github.com>
 <yXBIskeCE5U-O3jc6jSwsYczdSGanoaMSXb6EazbXyE=.ad5c5334-07e9-4edb-9743-ffbe554a5cba@github.com>
 <9_5byOZc3b5-zKH7LFe12s2OKdp6RQ_k4Iq1hZTp32g=.482bd52f-19d0-4d02-b318-f455570a897a@github.com>
 <Lrfc3wDRxopyuKdf53irwa88m-IPrH0Y7f59Zo2yhmY=.0f0d2eed-431b-4aca-826d-ee1b31cb004e@github.com>
 <OEMH8UN24jWqBcC6EItenNGlc-tsH1wIk_v
 79bBcVuk=.9ce8d383-484f-45bd-98d3-6f3430345ea8@github.com>
 <LUmB4qJuitWI8hHgzNe85teVtzW-w5tR41GtCgzPtE4=.045fed4e-78be-42ab-8055-5c3698767028@github.com>
Message-ID: <j3QmuGWDvDN7iWwvwqXiUWpd_yROJvISM8868Fv4mX8=.74f5e51e-d2c3-4f83-90e6-bf12000a08b8@github.com>

On Mon, 14 Sep 2020 21:07:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I am also 100% okay with just removing the random assertion. We have a whole bunch of other block iteration code in GC
>> code that does not sprinkle random asserts about what patterns of markWords are supposedly good or bad in live/dead
>> objects. And I also don't get what kind of bug this would catch.
>
> Okay. Since @coleenp, @rkennke and @fisk want that assertion to "hit the road",
> I'm in the process of removing it... build running now (just 'cause I'm paranoid me...)...

This sub-thread should be resolve via
https://github.com/openjdk/jdk/pull/135/commits/eeb9d761374ea193a7295fcce3ffe9707a8f0348

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Mon Sep 14 21:15:00 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Sep 2020 21:15:00 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/135/files
  - new: https://git.openjdk.java.net/jdk/pull/135/files/9fa2bed1..eeb9d761

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/135/head:pull/135

PR: https://git.openjdk.java.net/jdk/pull/135

From adityam at openjdk.java.net  Mon Sep 14 21:42:22 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Mon, 14 Sep 2020 21:42:22 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change
In-Reply-To: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
Message-ID: <r4nvj0lVB0YvW1RSBOeJeKr8Fmoc1NLkquu65CnODpE=.fac81fe4-71a9-469b-a14e-4dcebcdcd6c7@github.com>

On Mon, 14 Sep 2020 05:16:11 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
> removed, and callers have been modified.  Testing done:
> tier1
> hotspot_gc_shenandoah

@kimbarrett Can you please take a look when you have time?

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From dholmes at openjdk.java.net  Tue Sep 15 01:58:12 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Sep 2020 01:58:12 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
Message-ID: <Dvr2UdbraD98g-O0cshS5AWlWHK6p_FfYwyvJye8aJk=.37a85ba3-1764-4494-a21e-f0d3823dd591@github.com>

On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dholmes at openjdk.java.net  Tue Sep 15 02:08:11 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Sep 2020 02:08:11 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <Dvr2UdbraD98g-O0cshS5AWlWHK6p_FfYwyvJye8aJk=.37a85ba3-1764-4494-a21e-f0d3823dd591@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
 <Dvr2UdbraD98g-O0cshS5AWlWHK6p_FfYwyvJye8aJk=.37a85ba3-1764-4494-a21e-f0d3823dd591@github.com>
Message-ID: <bjAeW6Bk2YmfuI77XPOUQS8FWZ6YHFXXY48iZl7TP3k=.85edc9cf-902d-4e71-83bc-45dd64e577d3@github.com>

On Tue, 15 Sep 2020 01:55:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.
>
> Marked as reviewed by dholmes (Reviewer).

Edit: I missed that this was already flagged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Tue Sep 15 09:40:51 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 15 Sep 2020 09:40:51 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change
In-Reply-To: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
Message-ID: <u8BbI6NmtA161jnA4wVKc8vU7ANIy2uWcQ1duQjVlBo=.f94d86da-8f74-42d9-b148-d1c7c2c414e5@github.com>

On Mon, 14 Sep 2020 05:16:11 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
> removed, and callers have been modified.  Testing done:
> tier1
> hotspot_gc_shenandoah

Thanks for fixing this. It's nice to see build-time decorators go. Naturally, when removing the resolve() function, we
can also remove a bunch of "_raw" functions in the runtime. Like there is no longer a need to distinguish between
field_addr and field_addr_raw. Or between base and base_raw. They were all introduced so that one of them could apply
the resolve barrier. The same goes for mark vs mark_raw and the other related mark accessor functions on oopDesc. I
think we want to get rid of that too, right?

-------------

Changes requested by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/146

From kbarrett at openjdk.java.net  Tue Sep 15 10:21:15 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 15 Sep 2020 10:21:15 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
Message-ID: <xiDc2zRJVF1ap8y8KGdBHCdmmBnOPPTzeCA9xnfNzVU=.518cd894-7194-472d-85ae-6ee4d0b3a8a4@github.com>

On Mon, 14 Sep 2020 18:55:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett CR - made minor changes to address Kim's code review.

src/hotspot/share/runtime/objectMonitor.cpp line 244:

> 242: }
> 243:
> 244: #ifdef ASSERT

There would be less `#ifdef ASSERT` clutter if just the body of check_object_context were conditionalized.  Then the
calls wouldn't need to be.  Your call...

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From kbarrett at openjdk.java.net  Tue Sep 15 10:21:12 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 15 Sep 2020 10:21:12 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
Message-ID: <b_2rIlgkmG_XvohDrvXLnPr_UXbKFuZEWWrc4rdQYns=.9c1d73b3-dcf1-41b1-b9d0-f0d5e1aad188@github.com>

On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.

Marked as reviewed by kbarrett (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From coleenp at openjdk.java.net  Tue Sep 15 12:11:59 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 15 Sep 2020 12:11:59 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
Message-ID: <6BzJKwek4JwQkNWvWZp0SCS78dMRtaPTRa4p_UAC0gc=.acc9d8f4-aaa4-4951-bff5-f6da6c467c90@github.com>

On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.

Thank you for removing it.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/135

From rkennke at openjdk.java.net  Tue Sep 15 12:25:04 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 15 Sep 2020 12:25:04 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
Message-ID: <aSRklt-AvmPYHkaCbe5p0yR3_qw-6sI0NECq2weT5u4=.8b12d438-de25-4ec9-8e0a-615b50ffba25@github.com>

On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.

Looks good to me!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/135

From sspitsyn at openjdk.java.net  Wed Sep 16 00:09:42 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 16 Sep 2020 00:09:42 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <1rj4zO-L65NEG1ZyUdi3YyJR3A6AOTeb5cBsmVOiJ4E=.40e51e90-4008-46ea-a451-526144312035@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <FUxLEfUVidWZ2-LJlR4GoWIlAV61bDF-pyBSYl8fi98=.5c533df8-e93a-44ef-8620-ed90755b7030@github.com>
 <C3fEfvgPuX4VsbtUMiWOcy42-TsypfgEgL-Wefp8KC0=.9be2e223-6211-45b9-acb7-563f8067f8d6@github.com>
 <K_Bz_OELObm82PGeA614-ZycobMJsTq4POIr-pTMFAQ=.7dbde28b-d00b-4462-a8b5-9a94fed3c839@github.com>
 <1rj4zO-L65NEG1ZyUdi3YyJR3A6AOTeb5cBsmVOiJ4E=.40e51e90-4008-46ea-a451-526144312035@github.com>
Message-ID: <mGJd0k62TyQebVtb73Mrkd-XS4cwzM1tvtEDiiZZxMM=.7a8b5c99-7167-4295-92be-dcb3b19f77e4@github.com>

On Mon, 14 Sep 2020 17:10:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I don't see anything in the HPROF format description that claims this is a strong root. At a minimum this seems to be a
>> behavioural change that would warrant a CSR request. This also seems to be something that the serviceability folk
>> should be made aware of and have a chance to comment on.
>
> I've taken a first pass at creating a CSR:
> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
> https://bugs.openjdk.java.net/browse/JDK-8253121

I've looked at the CSR and added myself as a reviewer.
We had a slack chat with Dan, and I agree that with a weak handle it would be racy/unsafe for
JVMTI_HEAP_REFERENCE_MONITOR calls back to be called. The ObjectMonitors do not pin objects anymore (there are no
strong refs from them), so it has to be okay to skip reporting the JVMTI_HEAP_REFERENCE_MONITOR and and
JVMTI_HEAP_ROOT_MONITOR (old Heap Walking API) reference types. The JVMTI does not need an update as other VM
implementations can still report these reference types. Alan added a comment to the CSR saying that memory profiling
tools that use the JVMTI functions (FollowReferences with jvmtiHeapReferenceCallback or IterateOverReachableObjects
with jvmtiHeapRootCallback) to iterate over the heap should not have a compatibility impact as these reference types
are just informational but adding a release note can be useful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From sspitsyn at openjdk.java.net  Wed Sep 16 00:23:48 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 16 Sep 2020 00:23:48 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <absDZyL7vdcMv7BqG7u5eEdDJjLcJ2nkMkETt8gdPGg=.2aeaed15-8543-458b-b6b7-0560a5578b9a@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <ExVVaITLKAVIH0GaprYE8g7xQ1GEAjChOAZGTGSO20o=.dc35b788-ffb7-40a6-850c-d80acc61ff9f@github.com>
 <fIRORdoOh98JWKtHayhYzkIvG74kMAvQK5uMp3fiQFU=.280c4ce1-2ff1-4efe-9240-5335268e90e6@github.com>
 <absDZyL7vdcMv7BqG7u5eEdDJjLcJ2nkMkETt8gdPGg=.2aeaed15-8543-458b-b6b7-0560a5578b9a@github.com>
Message-ID: <v1rR8PjKwrigFIX4kSyHYrcZAutg39RD8FTtEac9gcU=.269d703a-d119-4e10-b0cc-ec35c607e046@github.com>

On Mon, 14 Sep 2020 17:10:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> From the spec I'm not clear on exactly what JVMTI_HEAP_REFERENCE_MONITOR is intended to be. Serviceability folk should
>> be giving some input here though.
>
> I've taken a first pass at creating a CSR:
> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
> https://bugs.openjdk.java.net/browse/JDK-8253121

Just a minor comment.
The line 1754 can be deleted as the JVMTI_HEAP_REFERENCE_MONITOR reference type will be never encountered:

1750 static jvmtiHeapRootKind toJvmtiHeapRootKind(jvmtiHeapReferenceKind kind) {
1751   switch (kind) {
1752     case JVMTI_HEAP_REFERENCE_JNI_GLOBAL:   return JVMTI_HEAP_ROOT_JNI_GLOBAL;
1753     case JVMTI_HEAP_REFERENCE_SYSTEM_CLASS: return JVMTI_HEAP_ROOT_SYSTEM_CLASS;
1754     case JVMTI_HEAP_REFERENCE_MONITOR:      return JVMTI_HEAP_ROOT_MONITOR;
1755     case JVMTI_HEAP_REFERENCE_STACK_LOCAL:  return JVMTI_HEAP_ROOT_STACK_LOCAL;
1756     case JVMTI_HEAP_REFERENCE_JNI_LOCAL:    return JVMTI_HEAP_ROOT_JNI_LOCAL;
1757     case JVMTI_HEAP_REFERENCE_THREAD:       return JVMTI_HEAP_ROOT_THREAD;
1758     case JVMTI_HEAP_REFERENCE_OTHER:        return JVMTI_HEAP_ROOT_OTHER;
1759     default: ShouldNotReachHere();          return JVMTI_HEAP_ROOT_OTHER;
1760   }
1761 }

Other than that the update in this file looks okay to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From sspitsyn at openjdk.java.net  Wed Sep 16 00:23:47 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 16 Sep 2020 00:23:47 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
Message-ID: <nDm5NaugXR7pVa0wN3q6JTO6MovjpyKPpKaJ_6RZAOU=.c15368a3-5a61-448e-b899-681bbd3256bd@github.com>

On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From gnu.andrew at redhat.com  Wed Sep 16 00:38:34 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 16 Sep 2020 01:38:34 +0100
Subject: [RFR] [8u] 8u272-b07 Upstream Sync
Message-ID: <20200916003834.GA202867@stopbrexit>

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

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

Changes in aarch64-shenandoah-jdk8u272-b07:
  - JDK-8246193: Possible NPE in ENC-PA-REP search in AS-REQ

Main issues of note:
None, clean merge (no HotSpot changes).

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/classes/sun/security/krb5/KrbKdcRep.java |   14 +++---
 b/test/sun/security/krb5/auto/AlwaysEncPaReq.java    |   40 +++++++++++++++++++
 b/test/sun/security/krb5/auto/KDC.java               |    5 +-
 4 files changed, 53 insertions(+), 7 deletions(-)

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

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le, aarch32 (Zero) & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 adityam at openjdk.java.net  Wed Sep 16 06:34:24 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Wed, 16 Sep 2020 06:34:24 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change
In-Reply-To: <u8BbI6NmtA161jnA4wVKc8vU7ANIy2uWcQ1duQjVlBo=.f94d86da-8f74-42d9-b148-d1c7c2c414e5@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <u8BbI6NmtA161jnA4wVKc8vU7ANIy2uWcQ1duQjVlBo=.f94d86da-8f74-42d9-b148-d1c7c2c414e5@github.com>
Message-ID: <brs1Xp_RGGIYgGZQ0dXs75PenKba_2uMuOKolkowQ3E=.dc0b4d85-d731-41eb-9be6-ff55b96a240e@github.com>

On Tue, 15 Sep 2020 09:37:50 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
>> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
>> removed, and callers have been modified.  Testing done:
>> tier1
>> hotspot_gc_shenandoah
>
> Thanks for fixing this. It's nice to see build-time decorators go. Naturally, when removing the resolve() function, we
> can also remove a bunch of "_raw" functions in the runtime. Like there is no longer a need to distinguish between
> field_addr and field_addr_raw. Or between base and base_raw. They were all introduced so that one of them could apply
> the resolve barrier. The same goes for mark vs mark_raw and the other related mark accessor functions on oopDesc. I
> think we want to get rid of that too, right?

@fisk Good point. It's clear that the field_addr and base ones can be changed, and I'll do that in the next update I
send. I'll take a closer look at the marking functions you mentioned as well. I want to understand the decorators
they're using and see whether they still do anything meaningful before I get rid of them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From eosterlund at openjdk.java.net  Wed Sep 16 06:41:04 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 16 Sep 2020 06:41:04 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change
In-Reply-To: <brs1Xp_RGGIYgGZQ0dXs75PenKba_2uMuOKolkowQ3E=.dc0b4d85-d731-41eb-9be6-ff55b96a240e@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <u8BbI6NmtA161jnA4wVKc8vU7ANIy2uWcQ1duQjVlBo=.f94d86da-8f74-42d9-b148-d1c7c2c414e5@github.com>
 <brs1Xp_RGGIYgGZQ0dXs75PenKba_2uMuOKolkowQ3E=.dc0b4d85-d731-41eb-9be6-ff55b96a240e@github.com>
Message-ID: <XOwP2cI09hJOnnbsDmyth_3leqKHNW4Lw4N2obc6bOY=.dda906a6-c571-4b63-b986-433c23a8e659@github.com>

On Wed, 16 Sep 2020 06:32:07 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> Thanks for fixing this. It's nice to see build-time decorators go. Naturally, when removing the resolve() function, we
>> can also remove a bunch of "_raw" functions in the runtime. Like there is no longer a need to distinguish between
>> field_addr and field_addr_raw. Or between base and base_raw. They were all introduced so that one of them could apply
>> the resolve barrier. The same goes for mark vs mark_raw and the other related mark accessor functions on oopDesc. I
>> think we want to get rid of that too, right?
>
> @fisk Good point. It's clear that the field_addr and base ones can be changed, and I'll do that in the next update I
> send. I'll take a closer look at the marking functions you mentioned as well. I want to understand the decorators
> they're using and see whether they still do anything meaningful before I get rid of them.

The only supported decorators for primitives is memory ordering decorators. These functions use MO_RELAXED. Specifying
MO_RELAXED is equivalent to using Atomic::load/store.

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From shade at redhat.com  Wed Sep 16 07:04:07 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 09:04:07 +0200
Subject: [RFR] [8u] 8u272-b07 Upstream Sync
In-Reply-To: <20200916003834.GA202867@stopbrexit>
References: <20200916003834.GA202867@stopbrexit>
Message-ID: <538fd32d-8ff9-2f75-db55-75bcefcfb02d@redhat.com>

On 9/16/20 2:38 AM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/jaxws/merge.changeset

Look trivially good.

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

Looks good.

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

Look trivially good.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From shade at openjdk.java.net  Wed Sep 16 08:12:10 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 08:12:10 GMT
Subject: RFR: 8253222: Shenandoah: unused AlwaysTrueClosure after JDK-8246591
Message-ID: <0yMF89TD1Adico64pRvKcqzKpqKO0FQTe183QoHphFQ=.9803e505-bc6c-468f-a264-b2f2c498b20d@github.com>

Static analysis shows the AlwaysTrueClosure is not needed in `ShenandoahRootScanner::roots_do` after JDK-8246591.

Testing: Linux x86_64 tier1_gc_shenandoah

-------------

Commit messages:
 - 8253222: Shenandoah: unused AlwaysTrueClosure after JDK-8246591

Changes: https://git.openjdk.java.net/jdk/pull/201/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=201&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253222
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/201/head:pull/201

PR: https://git.openjdk.java.net/jdk/pull/201

From shade at openjdk.java.net  Wed Sep 16 08:24:09 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 08:24:09 GMT
Subject: RFR: 8253224: Shenandoah: ShenandoahStrDedupQueue destructor calls
 virtual num_queues()
Message-ID: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>

Static analysis complains that `ShenandoahStrDedupQueue` destructor calls virtual `num_queues()`. We can just do the
`_nv` version to make this right.

Testing: hotspot_gc_shenandoah

-------------

Commit messages:
 - 8253224: Shenandoah: ShenandoahStrDedupQueue destructor calls virtual num_queues()

Changes: https://git.openjdk.java.net/jdk/pull/202/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=202&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253224
  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/202.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/202/head:pull/202

PR: https://git.openjdk.java.net/jdk/pull/202

From eosterlund at openjdk.java.net  Wed Sep 16 08:26:17 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 16 Sep 2020 08:26:17 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <nDm5NaugXR7pVa0wN3q6JTO6MovjpyKPpKaJ_6RZAOU=.c15368a3-5a61-448e-b899-681bbd3256bd@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
 <nDm5NaugXR7pVa0wN3q6JTO6MovjpyKPpKaJ_6RZAOU=.c15368a3-5a61-448e-b899-681bbd3256bd@github.com>
Message-ID: <EGxVBnVv2wa4F4U8GQmAgmDa_GsxNJzf5Orqfvo9ryM=.3944d739-aec4-4c8e-a0a5-9bbe85d8145a@github.com>

On Wed, 16 Sep 2020 00:21:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.
>
> Marked as reviewed by sspitsyn (Reviewer).

I added a release note (https://bugs.openjdk.java.net/browse/JDK-8253225) describing that these roots are now weak, and
hence won't be reported. Please have a look at that, to make sure what I am describing makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From shade at openjdk.java.net  Wed Sep 16 08:36:48 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 08:36:48 GMT
Subject: RFR: 8253226: Shenandoah: remove unimplemented
 ShenandoahStrDedupQueue::verify
Message-ID: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>

`ShenandoahStrDedupQueue` defers to super-class that in turn calls `verify_impl()`. `verify()` is left unused and
unimplemented. Static analysis complains about it.

Testing: Linux x86_64 fastdebug tier1_gc_shenandoah

-------------

Commit messages:
 - 8253226: Shenandoah: remove unimplemented ShenandoahStrDedupQueue::verify

Changes: https://git.openjdk.java.net/jdk/pull/203/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=203&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253226
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/203.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/203/head:pull/203

PR: https://git.openjdk.java.net/jdk/pull/203

From aph at redhat.com  Wed Sep 16 08:41:10 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 16 Sep 2020 09:41:10 +0100
Subject: [8] RFR: Shenandoah: JNI weak roots are always cleared before
 Full GC mark
In-Reply-To: <1745448f-407e-6692-25ef-bd2f089dfa1e@redhat.com>
References: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
 <71fcd54ee8eccd5c1982c2caedef2f05e08d55bf.camel@redhat.com>
 <1745448f-407e-6692-25ef-bd2f089dfa1e@redhat.com>
Message-ID: <a0dd942a-1058-c7b4-a71b-fd732b37370b@redhat.com>

On 22/06/2020 18:58, Aleksey Shipilev wrote:
> 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

It's not. None of what Google finds form that query, at least on the
first few pages.

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

"Work around that problem" would be better than either.

-- 
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 openjdk.java.net  Wed Sep 16 09:25:32 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 16 Sep 2020 09:25:32 GMT
Subject: RFR: 8253222: Shenandoah: unused AlwaysTrueClosure after
 JDK-8246591
In-Reply-To: <0yMF89TD1Adico64pRvKcqzKpqKO0FQTe183QoHphFQ=.9803e505-bc6c-468f-a264-b2f2c498b20d@github.com>
References: <0yMF89TD1Adico64pRvKcqzKpqKO0FQTe183QoHphFQ=.9803e505-bc6c-468f-a264-b2f2c498b20d@github.com>
Message-ID: <ozHeBWgLsc2y2-o_Df5eO4KYgIYKqLmHdnXzKiJJjfo=.1316543f-c1c5-47ae-888c-372ee28d62ef@github.com>

On Wed, 16 Sep 2020 08:06:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Static analysis shows the AlwaysTrueClosure is not needed in `ShenandoahRootScanner::roots_do` after JDK-8246591.
> 
> Testing: Linux x86_64 tier1_gc_shenandoah

Looks good. Thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/201

From shade at openjdk.java.net  Wed Sep 16 09:28:39 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 09:28:39 GMT
Subject: Integrated: 8253222: Shenandoah: unused AlwaysTrueClosure after
 JDK-8246591
In-Reply-To: <0yMF89TD1Adico64pRvKcqzKpqKO0FQTe183QoHphFQ=.9803e505-bc6c-468f-a264-b2f2c498b20d@github.com>
References: <0yMF89TD1Adico64pRvKcqzKpqKO0FQTe183QoHphFQ=.9803e505-bc6c-468f-a264-b2f2c498b20d@github.com>
Message-ID: <6Pn6YQHDCDKiMWpRxV2nWmy85moMm7hGsKJEW2KwVNM=.dcc5f9a9-c93f-47fa-9daf-908cf3df5dfb@github.com>

On Wed, 16 Sep 2020 08:06:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Static analysis shows the AlwaysTrueClosure is not needed in `ShenandoahRootScanner::roots_do` after JDK-8246591.
> 
> Testing: Linux x86_64 tier1_gc_shenandoah

This pull request has now been integrated.

Changeset: dd435331
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dd435331
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8253222: Shenandoah: unused AlwaysTrueClosure after JDK-8246591

Reviewed-by: rkennke

-------------

PR: https://git.openjdk.java.net/jdk/pull/201

From rkennke at openjdk.java.net  Wed Sep 16 09:29:40 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 16 Sep 2020 09:29:40 GMT
Subject: RFR: 8253224: Shenandoah: ShenandoahStrDedupQueue destructor
 calls virtual num_queues()
In-Reply-To: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>
References: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>
Message-ID: <gJtUuKhSzRRAsVzYelcnJIXFM_GByxC_rchdacdvvEc=.2c68e76d-b280-4834-a767-043c3aa1064f@github.com>

On Wed, 16 Sep 2020 08:16:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Static analysis complains that `ShenandoahStrDedupQueue` destructor calls virtual `num_queues()`. We can just do the
> `_nv` version to make this right.
> Testing: hotspot_gc_shenandoah

Ok, looks good! Thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/202

From rkennke at openjdk.java.net  Wed Sep 16 09:30:51 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 16 Sep 2020 09:30:51 GMT
Subject: RFR: 8253226: Shenandoah: remove unimplemented
 ShenandoahStrDedupQueue::verify
In-Reply-To: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>
References: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>
Message-ID: <RVSzNqnGcFxYgglv2HHlTr4FToZkXz8UNAtesMp61mo=.9fcdf525-69b3-4c39-a033-35b8e3214a4f@github.com>

On Wed, 16 Sep 2020 08:29:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `ShenandoahStrDedupQueue` defers to super-class that in turn calls `verify_impl()`. `verify()` is left unused and
> unimplemented. Static analysis complains about it.
> Testing: Linux x86_64 fastdebug tier1_gc_shenandoah

Marked as reviewed by rkennke (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/203

From shade at openjdk.java.net  Wed Sep 16 12:07:17 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 12:07:17 GMT
Subject: RFR: 8253226: Shenandoah: remove unimplemented
 ShenandoahStrDedupQueue::verify
In-Reply-To: <RVSzNqnGcFxYgglv2HHlTr4FToZkXz8UNAtesMp61mo=.9fcdf525-69b3-4c39-a033-35b8e3214a4f@github.com>
References: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>
 <RVSzNqnGcFxYgglv2HHlTr4FToZkXz8UNAtesMp61mo=.9fcdf525-69b3-4c39-a033-35b8e3214a4f@github.com>
Message-ID: <ZtkP1ARckJY5RdTWyUrpv0kiM13atQi33tv8eROvgQQ=.fa0f7d87-c38e-47c4-9903-22f73f9ff716@github.com>

On Wed, 16 Sep 2020 09:28:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> `ShenandoahStrDedupQueue` defers to super-class that in turn calls `verify_impl()`. `verify()` is left unused and
>> unimplemented. Static analysis complains about it.
>> Testing: Linux x86_64 fastdebug tier1_gc_shenandoah
>
> Marked as reviewed by rkennke (Reviewer).

@zhengyu123, would you like to ack too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/203

From shade at openjdk.java.net  Wed Sep 16 12:08:01 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 12:08:01 GMT
Subject: RFR: 8253224: Shenandoah: ShenandoahStrDedupQueue destructor
 calls virtual num_queues()
In-Reply-To: <gJtUuKhSzRRAsVzYelcnJIXFM_GByxC_rchdacdvvEc=.2c68e76d-b280-4834-a767-043c3aa1064f@github.com>
References: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>
 <gJtUuKhSzRRAsVzYelcnJIXFM_GByxC_rchdacdvvEc=.2c68e76d-b280-4834-a767-043c3aa1064f@github.com>
Message-ID: <I_uy5HCQSqxJVhc-OMLA_6QW8Saxh-yGHG9X9pA20vY=.1d0e0360-d4cd-4acd-8e73-8f4254c73700@github.com>

On Wed, 16 Sep 2020 09:26:35 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Static analysis complains that `ShenandoahStrDedupQueue` destructor calls virtual `num_queues()`. We can just do the
>> `_nv` version to make this right.
>> Testing: hotspot_gc_shenandoah
>
> Ok, looks good! Thank you!

@zhengyu123, would you like to ack too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/202

From zgu at openjdk.java.net  Wed Sep 16 12:19:43 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 12:19:43 GMT
Subject: RFR: 8253224: Shenandoah: ShenandoahStrDedupQueue destructor
 calls virtual num_queues()
In-Reply-To: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>
References: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>
Message-ID: <LjM-6iZQqxkJahbmhmBcQM1b1QZ2alqVbWrHlfaJsnQ=.7f1106be-05cc-44de-aeb9-2e1f301a6c88@github.com>

On Wed, 16 Sep 2020 08:16:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Static analysis complains that `ShenandoahStrDedupQueue` destructor calls virtual `num_queues()`. We can just do the
> `_nv` version to make this right.
> Testing: hotspot_gc_shenandoah

Marked as reviewed by zgu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/202

From shade at openjdk.java.net  Wed Sep 16 12:19:45 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 12:19:45 GMT
Subject: Integrated: 8253224: Shenandoah: ShenandoahStrDedupQueue destructor
 calls virtual num_queues()
In-Reply-To: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>
References: <a73zyBeMXQGEV1GSCuo0IrQJEEau7ycHJ9IofvG_IrY=.9ffb7eae-0651-4eda-9018-d871a2359369@github.com>
Message-ID: <2frBVnwKXO1fO25ldbVmHJKT3QTFHeEkFX4ts2_pU2c=.2a0621b2-6855-4c18-a6ac-437a48f4ff7d@github.com>

On Wed, 16 Sep 2020 08:16:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Static analysis complains that `ShenandoahStrDedupQueue` destructor calls virtual `num_queues()`. We can just do the
> `_nv` version to make this right.
> Testing: hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: c781594b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c781594b
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8253224: Shenandoah: ShenandoahStrDedupQueue destructor calls virtual num_queues()

Reviewed-by: rkennke, zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/202

From zgu at openjdk.java.net  Wed Sep 16 12:21:01 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 12:21:01 GMT
Subject: RFR: 8253226: Shenandoah: remove unimplemented
 ShenandoahStrDedupQueue::verify
In-Reply-To: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>
References: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>
Message-ID: <haGVVpvWFALuHhDALjeQfXX4puhkjxxzS-3udMRhe9k=.f11d9adc-1b43-42db-b761-d5b9b389c4a4@github.com>

On Wed, 16 Sep 2020 08:29:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `ShenandoahStrDedupQueue` defers to super-class that in turn calls `verify_impl()`. `verify()` is left unused and
> unimplemented. Static analysis complains about it.
> Testing: Linux x86_64 fastdebug tier1_gc_shenandoah

Marked as reviewed by zgu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/203

From shade at openjdk.java.net  Wed Sep 16 12:21:01 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 12:21:01 GMT
Subject: Integrated: 8253226: Shenandoah: remove unimplemented
 ShenandoahStrDedupQueue::verify
In-Reply-To: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>
References: <5wRsFG5GrkoD1l3Ay2RKyXKQLBKr7awRK4qdRQW-us0=.375aee78-a0e9-49ed-860b-1ecac8adf5ab@github.com>
Message-ID: <hmuRvXKx7CkF5lm8psbj0Ww9J9vijJTI1sfTQPmIwHc=.a963b4b9-8b3f-4cad-985b-1fedd3a0c900@github.com>

On Wed, 16 Sep 2020 08:29:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `ShenandoahStrDedupQueue` defers to super-class that in turn calls `verify_impl()`. `verify()` is left unused and
> unimplemented. Static analysis complains about it.
> Testing: Linux x86_64 fastdebug tier1_gc_shenandoah

This pull request has now been integrated.

Changeset: 300b8517
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/300b8517
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8253226: Shenandoah: remove unimplemented ShenandoahStrDedupQueue::verify

Reviewed-by: rkennke, zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/203

From zgu at openjdk.java.net  Wed Sep 16 14:08:59 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 14:08:59 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
Message-ID: <Si21xNKapBzq1WWZOd4cbTutrzwRmmQnIw2Nwk9l27M=.4fc72a2c-d328-4cc2-a239-c0a067012cfe@github.com>

On Sat, 12 Sep 2020 00:17:58 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> - enable parallel heap inspecton for ShenandoahHeap
>>   - preliminary evaluation:
>>     Time of jmap histo on (8GB heap with 4GB objects)
>>     * before: 5.186s
>>     * after : 1.698s
>
> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
> will show differences compared to the previous content of the PR. The pull request contains one new commit since the
> last revision:
>   8252104: parallel heap inspection for ShenandoahHeap
>   
>     - enable parallel heap inspecton for ShenandoahHeap
>     - preliminary evaluation:
>       Time of jmap histo on (8GB heap with 4GB objects)
>       * before: 5.186s
>       * after : 1.698s

Marked as reviewed by zgu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From zgu at openjdk.java.net  Wed Sep 16 14:08:59 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 14:08:59 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <Aht9s7WTezQC8tm5vs7zCCN5JA9nUG2VgZdv_pNt1hE=.38a95082-5f52-4735-ad39-ce85a569d014@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <7EENV89Ll-5SfAYp7OZsxgYRUikXqWibts1jyRKE45s=.f9d2fdba-1777-4ebd-b3dc-e9b41e602a75@github.com>
 <KybrQhWK_lSIFHMxPpyvr2--klhFMsAebgnsjVnU58I=.2d6e3024-f4ba-4814-b13d-a29226eba551@github.com>
 <P22B2myTT81fixG8IXWLu-8toxLF41sgfN5MQygJ0FA=.5811a18e-b210-41ca-8694-56601d8ee351@github.com>
 <3Z4xrVeHZ_d5Rcdn41HQUdMm9kdof-CSURtjFYn2lSg=.fa43943f-3175-43ef-8f8e-498ad6fe6512@github.com>
 <G7wEqabDpLMebETgcCafU0weoaujEB4VYL9YMp8XNX4=.8814ecf2-f9b3-48fe-97fa-59de5a0a92ba@github.com>
 <Aht9s7WTezQC8tm5vs7zCCN5JA9nUG2VgZdv_pNt1hE=.38a95082-5f52-4735-ad39-ce85a569d014@github.com>
Message-ID: <qmLNZkhitRN_Vr-DVxWY2MzB9mQ9g4UtEAf6pXP9arc=.dbb6d06e-aeb3-4fb0-87a8-6913faa95e5c@github.com>

On Sat, 12 Sep 2020 00:15:06 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Hi @zhengyu123 ,
> Thanks for your comments! I have refined the code and update the PR.
> -Lin

Looks good to me.
@shipilev may want to take a look.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From zgu at openjdk.java.net  Wed Sep 16 15:14:04 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 15:14:04 GMT
Subject: RFR: 8253244: Shenandoah: cleanup includes in Shenandoah root
 processor files
Message-ID: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>

Many roots were moved to oop storages, Shenandoah root processor no longer references to StringTable, systemDictionary
and ResolvedMethodTable, etc.

-------------

Commit messages:
 - JDK-8253244

Changes: https://git.openjdk.java.net/jdk/pull/206/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=206&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253244
  Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/206.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/206/head:pull/206

PR: https://git.openjdk.java.net/jdk/pull/206

From shade at openjdk.java.net  Wed Sep 16 15:21:31 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Sep 2020 15:21:31 GMT
Subject: RFR: 8253244: Shenandoah: cleanup includes in Shenandoah root
 processor files
In-Reply-To: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>
References: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>
Message-ID: <FH3mCJkY4imEOJBDGciW0V-Jrmj-B-GCDCFKLlGr3oA=.b76f2cce-2de7-46b9-99d6-55ab71134c91@github.com>

On Wed, 16 Sep 2020 15:05:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Many roots were moved to oop storages, Shenandoah root processor no longer references to StringTable, systemDictionary
> and ResolvedMethodTable, etc.

Looks fine. Please try with {release, fastdebug, slowdebug} x {-PCH, +PCH}?

I use scripts like these:

`#!/bin/bash

set -euo pipefail

for M in release fastdebug slowdebug; do
  sh ./configure --with-debug-level=$M --with-boot-jdk=/home/shade/Install/jdk14-ea/
  CONF=linux-x86_64-server-$M make clean images

  sh ./configure --with-debug-level=$M --with-boot-jdk=/home/shade/Install/jdk14-ea/ --disable-precompiled-headers
  CONF=linux-x86_64-server-$M make clean images
done
`

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/206

From zgu at openjdk.java.net  Wed Sep 16 15:39:46 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 15:39:46 GMT
Subject: Withdrawn: 8253244: Shenandoah: cleanup includes in Shenandoah root
 processor files
In-Reply-To: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>
References: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>
Message-ID: <VpL3oZfBXOZ3emaNLFySvGDSAJNdIan2qRdvhsXKdkQ=.5457fca7-f781-4d04-8702-a7c6ca9c6ed3@github.com>

On Wed, 16 Sep 2020 15:05:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Many roots were moved to oop storages, Shenandoah root processor no longer references to StringTable, systemDictionary
> and ResolvedMethodTable, etc.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/206

From dcubed at openjdk.java.net  Wed Sep 16 15:42:53 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Sep 2020 15:42:53 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]
In-Reply-To: <xiDc2zRJVF1ap8y8KGdBHCdmmBnOPPTzeCA9xnfNzVU=.518cd894-7194-472d-85ae-6ee4d0b3a8a4@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <GqjBX7VfOqTkkyQUZFPNQ1J2HGTn_kaYpUA8mUfAc0s=.6329d3a6-a2b6-4d05-ab09-7b1335536f9f@github.com>
 <xiDc2zRJVF1ap8y8KGdBHCdmmBnOPPTzeCA9xnfNzVU=.518cd894-7194-472d-85ae-6ee4d0b3a8a4@github.com>
Message-ID: <k1rj0KOxqn3vxG84-Nr2ttb05iom3Cd60ri-5yQLI10=.1147b817-fb15-4eee-be86-bcf8ae98c374@github.com>

On Tue, 15 Sep 2020 10:17:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kimbarrett CR - made minor changes to address Kim's code review.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 244:
> 
>> 242: }
>> 243:
>> 244: #ifdef ASSERT
> 
> There would be less `#ifdef ASSERT` clutter if just the body of check_object_context were conditionalized.  Then the
> calls wouldn't need to be.  Your call...

I'll make that change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Wed Sep 16 15:45:32 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Sep 2020 15:45:32 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <v1rR8PjKwrigFIX4kSyHYrcZAutg39RD8FTtEac9gcU=.269d703a-d119-4e10-b0cc-ec35c607e046@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <ExVVaITLKAVIH0GaprYE8g7xQ1GEAjChOAZGTGSO20o=.dc35b788-ffb7-40a6-850c-d80acc61ff9f@github.com>
 <fIRORdoOh98JWKtHayhYzkIvG74kMAvQK5uMp3fiQFU=.280c4ce1-2ff1-4efe-9240-5335268e90e6@github.com>
 <absDZyL7vdcMv7BqG7u5eEdDJjLcJ2nkMkETt8gdPGg=.2aeaed15-8543-458b-b6b7-0560a5578b9a@github.com>
 <v1rR8PjKwrigFIX4kSyHYrcZAutg39RD8FTtEac9gcU=.269d703a-d119-4e10-b0cc-ec35c607e046@github.com>
Message-ID: <JC1TqJa2DKf-oVbJ0GkawygcPpLCzb1308mC0Fo-wUw=.4e15d121-59eb-45a6-b0ba-b495b9f1bccb@github.com>

On Wed, 16 Sep 2020 00:20:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I've taken a first pass at creating a CSR:
>> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
>> https://bugs.openjdk.java.net/browse/JDK-8253121
>
> Just a minor comment.
> The line 1754 can be deleted as the JVMTI_HEAP_REFERENCE_MONITOR reference type will be never encountered:
> 
> 1750 static jvmtiHeapRootKind toJvmtiHeapRootKind(jvmtiHeapReferenceKind kind) {
> 1751   switch (kind) {
> 1752     case JVMTI_HEAP_REFERENCE_JNI_GLOBAL:   return JVMTI_HEAP_ROOT_JNI_GLOBAL;
> 1753     case JVMTI_HEAP_REFERENCE_SYSTEM_CLASS: return JVMTI_HEAP_ROOT_SYSTEM_CLASS;
> 1754     case JVMTI_HEAP_REFERENCE_MONITOR:      return JVMTI_HEAP_ROOT_MONITOR;
> 1755     case JVMTI_HEAP_REFERENCE_STACK_LOCAL:  return JVMTI_HEAP_ROOT_STACK_LOCAL;
> 1756     case JVMTI_HEAP_REFERENCE_JNI_LOCAL:    return JVMTI_HEAP_ROOT_JNI_LOCAL;
> 1757     case JVMTI_HEAP_REFERENCE_THREAD:       return JVMTI_HEAP_ROOT_THREAD;
> 1758     case JVMTI_HEAP_REFERENCE_OTHER:        return JVMTI_HEAP_ROOT_OTHER;
> 1759     default: ShouldNotReachHere();          return JVMTI_HEAP_ROOT_OTHER;
> 1760   }
> 1761 }
> 
> Other than that the update in this file looks okay to me.

I cleaned that up. The only references to JVMTI_HEAP_REFERENCE_MONITOR and
JVMTI_HEAP_ROOT_MONITOR that remain are in the spec:

$ egrep -r 'JVMTI_HEAP_REFERENCE_MONITOR|JVMTI_HEAP_ROOT_MONITOR' src/hotspot
src/hotspot/share/prims/jvmti.xml:          <constant id="JVMTI_HEAP_REFERENCE_MONITOR" num="23">
src/hotspot/share/prims/jvmti.xml:          <constant id="JVMTI_HEAP_ROOT_MONITOR" num="3">
src/hotspot/share/prims/jvmti.xml:              <code>JVMTI_HEAP_ROOT_MONITOR</code>,

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Wed Sep 16 15:56:40 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Sep 2020 15:56:40 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <mGJd0k62TyQebVtb73Mrkd-XS4cwzM1tvtEDiiZZxMM=.7a8b5c99-7167-4295-92be-dcb3b19f77e4@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <suOyUaCJBqqZiycuLockM6VtH2Y_Wxr3QNvYiNrJHZc=.45aec8f8-473b-49b4-b9b9-de04c9218882@github.com>
 <vnX3-CjvaOdEbitOqgzueQqjJsgxT68dizCK2k2AORg=.1f9414fc-0c2f-45f0-aabc-9d206d5f19a5@github.com>
 <7dfBMb2-EUEqKgml97ffFb50rxEO_djF85-X8AKLfUg=.9deac832-6d24-4277-8651-b9bfa7d5a397@github.com>
 <LTDIKTiBZz10bJ0obh1MuXVhSIHlkg52NqJcFlIrWK8=.642c74e6-0afe-4279-8621-3694657ecc35@github.com>
 <FUxLEfUVidWZ2-LJlR4GoWIlAV61bDF-pyBSYl8fi98=.5c533df8-e93a-44ef-8620-ed90755b7030@github.com>
 <C3fEfvgPuX4VsbtUMiWOcy42-TsypfgEgL-Wefp8KC0=.9be2e223-6211-45b9-acb7-563f8067f8d6@github.com>
 <K_Bz_OELObm82PGeA614-ZycobMJsTq4POIr-pTMFAQ=.7dbde28b-d00b-4462-a8b5-9a94fed3c839@github.com>
 <1rj4zO-L65NEG1ZyUdi3YyJR3A6AOTeb5cBsmVOiJ4E=.40e51e90-4008-46ea-a451-526144312035@github.com>
 <mGJd0k62TyQebVtb73Mrkd-XS4cwzM1tvtEDiiZZxMM=.7a8b5c99-7167-4295-92be-dcb3b19f77e4@github.com>
Message-ID: <um55-26KQB6hfgs_hEInaCm8Sn2mmzfRvvRkmYaeWT4=.721f138d-f0b9-495d-b1a7-d62da34f113a@github.com>

On Wed, 16 Sep 2020 00:07:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I've taken a first pass at creating a CSR:
>> JDK-8253121 migrate ObjectMonitor::_object to OopStorage
>> https://bugs.openjdk.java.net/browse/JDK-8253121
>
> I've looked at the CSR and added myself as a reviewer.
> We had a slack chat with Dan, and I agree that with a weak handle it would be racy/unsafe for
> JVMTI_HEAP_REFERENCE_MONITOR calls back to be called. The ObjectMonitors do not pin objects anymore (there are no
> strong refs from them), so it has to be okay to skip reporting the JVMTI_HEAP_REFERENCE_MONITOR and and
> JVMTI_HEAP_ROOT_MONITOR (old Heap Walking API) reference types. The JVMTI does not need an update as other VM
> implementations can still report these reference types. Alan added a comment to the CSR saying that memory profiling
> tools that use the JVMTI functions (FollowReferences with jvmtiHeapReferenceCallback or IterateOverReachableObjects
> with jvmtiHeapRootCallback) to iterate over the heap should not have a compatibility impact as these reference types
> are just informational but adding a release note can be useful.

Slight clarification. Serguei and I were discussing whether we could continue
to make JVMTI_HEAP_REFERENCE_MONITOR call backs or emit
HPROF_GC_ROOT_MONITOR_USED entries in heap dump output as a
way to ease the transition phase of getting used to these things going
away. My answer was that we could do that but it would racy and unsafe
due to the ObjectMonitor's object being GC'ed.

It's also incorrect to make JVMTI_HEAP_REFERENCE_MONITOR call backs
or emit HPROF_GC_ROOT_MONITOR_USED entries in heap dump once
the ObjectMonitor's object ref becomes a weak handle. That weak handle
no longer prevents the associated object from being GC'ed so it is no
longer a strong root.

See Erik's comment above: https://github.com/openjdk/jdk/pull/135#discussion_r487291746

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Wed Sep 16 16:02:16 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Sep 2020 16:02:16 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <EGxVBnVv2wa4F4U8GQmAgmDa_GsxNJzf5Orqfvo9ryM=.3944d739-aec4-4c8e-a0a5-9bbe85d8145a@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
 <nDm5NaugXR7pVa0wN3q6JTO6MovjpyKPpKaJ_6RZAOU=.c15368a3-5a61-448e-b899-681bbd3256bd@github.com>
 <EGxVBnVv2wa4F4U8GQmAgmDa_GsxNJzf5Orqfvo9ryM=.3944d739-aec4-4c8e-a0a5-9bbe85d8145a@github.com>
Message-ID: <r9fbDzrlyZJKwhNGKY4Rzk6A4mZPVRcUu5yjTmZ3y_k=.f24b49a6-abe8-4c30-817a-4fc521c1d16c@github.com>

On Wed, 16 Sep 2020 08:23:03 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Marked as reviewed by sspitsyn (Reviewer).
>
> I added a release note (https://bugs.openjdk.java.net/browse/JDK-8253225) describing that these roots are now weak, and
> hence won't be reported. Please have a look at that, to make sure what I am describing makes sense.

@kimbarrett - Thanks for the cleanup suggestion.
@sspitsyn - Thanks for the review.
I've gone ahead and "resolved" the comments that were addressed by previous commits.
I've made changes for both Kim and Serguei's reviews. Building those bits now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From thevenet.fred at free.fr  Wed Sep 16 16:13:14 2020
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Wed, 16 Sep 2020 18:13:14 +0200 (CEST)
Subject: Is option "ShenandoahAllocationThreshold" still experimental in
 OpenJDK15 ?
Message-ID: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>

Hi, 

I've been using ShenandoahGC since the release of OpenJDK 13 (as provided by Azul[1]) to benefit from its " ShenandoahGCHeuristics=compact" option which is a good fit for my need (a generally small, non critical, client application with transient needs for a larger heap). 

More specifically, I use the following parameters: -XX: +UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:ShenandoahAllocationThreshold=20 

Starting with 15, I was under the impression I no longer needed to set +UnlockExperimentalVMOptions, to use the above options. Yet starting a JVM with without unlocking experimental options yields the following error: "Error: VM option 'ShenandoahAllocationThreshold' is experimental and must be enabled via -XX:+UnlockExperimentalVMOptions." 

If I simply omit "ShenandoahAllocationThreshold", then the JVM starts. 

Is this the expected behaviour? If so, is there a list of Shenandoah- specific options that are still experimental somewhere? 

Thanks 

-- Fred. 


[1] https://www.azul.com/downloads/zulu-community/?architecture=x86-64-bit&package=jdk 

From dcubed at openjdk.java.net  Wed Sep 16 16:13:23 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Sep 2020 16:13:23 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]
In-Reply-To: <b_2rIlgkmG_XvohDrvXLnPr_UXbKFuZEWWrc4rdQYns=.9c1d73b3-dcf1-41b1-b9d0-f0d5e1aad188@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <uW-xhYo6dSQTZwuQRAYhHBRdyYV7Aqvh-_qjF4CSwAA=.5bc498c6-7f3d-4b7c-a98e-cfdb342cf0bc@github.com>
 <b_2rIlgkmG_XvohDrvXLnPr_UXbKFuZEWWrc4rdQYns=.9c1d73b3-dcf1-41b1-b9d0-f0d5e1aad188@github.com>
Message-ID: <BkLhkzQwSYhiAc4XU8li6UKKGF_8VT8ZdMM1brhfRLI=.1f612b27-fa91-42b3-acdd-4b10a4bb5a00@github.com>

On Tue, 15 Sep 2020 10:17:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rkennke, coleenp, fisk CR - delete random assert() that knows too much about markWords.
>
> Marked as reviewed by kbarrett (Reviewer).

@kimbarrett and @sspitsyn - Your most recent comments should be resolved via
https://github.com/openjdk/jdk/pull/135/commits/215084ac7ef481713560d14498ce420a40ca813a.

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From dcubed at openjdk.java.net  Wed Sep 16 16:13:23 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Sep 2020 16:13:23 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Minor changes/deletions to address kimbarrett and sspitsyn CR comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/135/files
  - new: https://git.openjdk.java.net/jdk/pull/135/files/eeb9d761..215084ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=135&range=04-05

  Stats: 9 lines in 2 files changed: 2 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/135/head:pull/135

PR: https://git.openjdk.java.net/jdk/pull/135

From gnu.andrew at redhat.com  Wed Sep 16 16:32:55 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 16 Sep 2020 17:32:55 +0100
Subject: [RFR] [8u] 8u272-b07 Upstream Sync
In-Reply-To: <538fd32d-8ff9-2f75-db55-75bcefcfb02d@redhat.com>
References: <20200916003834.GA202867@stopbrexit>
 <538fd32d-8ff9-2f75-db55-75bcefcfb02d@redhat.com>
Message-ID: <20200916163255.GH258227@stopbrexit>

On 09:04 Wed 16 Sep     , Aleksey Shipilev wrote:
> On 9/16/20 2:38 AM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/jaxws/merge.changeset
> 
> Look trivially good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/jdk/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/hotspot/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b07/root/merge.changeset
> 
> Look trivially good.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks. Pushed.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 holger at applied-asynchrony.com  Wed Sep 16 16:36:25 2020
From: holger at applied-asynchrony.com (=?UTF-8?Q?Holger_Hoffst=c3=a4tte?=)
Date: Wed, 16 Sep 2020 18:36:25 +0200
Subject: Is option "ShenandoahAllocationThreshold" still experimental in
 OpenJDK15 ?
In-Reply-To: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>
References: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>
Message-ID: <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>

On 2020-09-16 18:13, thevenet.fred at free.fr wrote:
> I've been using ShenandoahGC since the release of OpenJDK 13 (as
> provided by Azul[1]) to benefit from its "
> ShenandoahGCHeuristics=compact" option which is a good fit for my
> need (a generally small, non critical, client application with
> transient needs for a larger heap).
> 
> More specifically, I use the following parameters: -XX:
> +UnlockExperimentalVMOptions -XX:+UseShenandoahGC
> -XX:ShenandoahGCHeuristics=compact
> -XX:ShenandoahAllocationThreshold=20

Where did you find my options? :D

> Starting with 15, I was under the impression I no longer needed to
> set +UnlockExperimentalVMOptions, to use the above options. Yet
> starting a JVM with without unlocking experimental options yields the
> following error: "Error: VM option 'ShenandoahAllocationThreshold' is
> experimental and must be enabled via
> -XX:+UnlockExperimentalVMOptions."
> 
> If I simply omit "ShenandoahAllocationThreshold", then the JVM
> starts.
> 
> Is this the expected behaviour? If so, is there a list of Shenandoah-
> specific options that are still experimental somewhere?

I don't think it's the expected behaviour (as of 15) and can confirm that
I get the same with the AdoptOpenJDK 15 binary that I'm currently testing,
so it's probably just an oversight/bug when parsing the arguments and
checking their status. AFAIK there is nothing experimental about the
ShenandoahAllocationThreshold flag itself or compact mode.

cheers
Holger

From sspitsyn at openjdk.java.net  Wed Sep 16 16:47:59 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 16 Sep 2020 16:47:59 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]
In-Reply-To: <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
Message-ID: <4iJsXcOdlCYUMtI9bwYTqG8YEgyV1CHa1VC0ZWkcQ9M=.470d0741-5aba-433b-8917-90a8cc019e0d@github.com>

On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes/deletions to address kimbarrett and sspitsyn CR comments.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From eosterlund at openjdk.java.net  Wed Sep 16 17:02:44 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 16 Sep 2020 17:02:44 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]
In-Reply-To: <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
Message-ID: <hMFJ6QUY8CXjT7V2fr3KSqrQBaekpoSfzqSGLTDCkBY=.97abc210-fbe6-4e5e-8f9e-e312e967d461@github.com>

On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes/deletions to address kimbarrett and sspitsyn CR comments.

Marked as reviewed by eosterlund (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From zgu at openjdk.java.net  Wed Sep 16 17:22:47 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 17:22:47 GMT
Subject: Integrated: 8253244: Shenandoah: cleanup includes in Shenandoah root
 processor files
In-Reply-To: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>
References: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>
Message-ID: <531cVHF2Omhybr8bAIO_t11HoXK_H7z_1PNsW2Cr82E=.aacff4ea-621b-448d-8897-71b790601851@github.com>

On Wed, 16 Sep 2020 15:05:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Many roots were moved to oop storages, Shenandoah root processor no longer references to StringTable, systemDictionary
> and ResolvedMethodTable, etc.

This pull request has now been integrated.

Changeset: d250f9e0
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d250f9e0
Stats:     7 lines in 2 files changed: 6 ins; 0 del; 1 mod

8253244: Shenandoah: cleanup includes in Shenandoah root processor files

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/206

From zgu at openjdk.java.net  Wed Sep 16 17:22:47 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 16 Sep 2020 17:22:47 GMT
Subject: RFR: 8253244: Shenandoah: cleanup includes in Shenandoah root
 processor files
In-Reply-To: <FH3mCJkY4imEOJBDGciW0V-Jrmj-B-GCDCFKLlGr3oA=.b76f2cce-2de7-46b9-99d6-55ab71134c91@github.com>
References: <iV-J-WWDwM4ZxmavjKrq82NB2V2fCahgYAyWunBOgvY=.720fce8e-1848-4411-b87b-2878c52a4cf9@github.com>
 <FH3mCJkY4imEOJBDGciW0V-Jrmj-B-GCDCFKLlGr3oA=.b76f2cce-2de7-46b9-99d6-55ab71134c91@github.com>
Message-ID: <XEs3WBzCWCD_7tW6fgA_b6gz_oBy1kiH8Mg12hrHCPo=.59356509-9c83-4d21-856f-493d6be101fe@github.com>

On Wed, 16 Sep 2020 15:19:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks fine. Please try with {release, fastdebug, slowdebug} x {-PCH, +PCH}?
> 
> I use scripts like these:
> 
> `#!/bin/bash
> 
> set -euo pipefail
> 
> for M in release fastdebug slowdebug; do
> sh ./configure --with-debug-level=$M --with-boot-jdk=/home/shade/Install/jdk14-ea/
> CONF=linux-x86_64-server-$M make clean images
> 
> sh ./configure --with-debug-level=$M --with-boot-jdk=/home/shade/Install/jdk14-ea/ --disable-precompiled-headers
> CONF=linux-x86_64-server-$M make clean images
> done
> `

All fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/206

From thevenet.fred at free.fr  Wed Sep 16 18:24:59 2020
From: thevenet.fred at free.fr (Frederic Thevenet)
Date: Wed, 16 Sep 2020 20:24:59 +0200
Subject: Is option "ShenandoahAllocationThreshold" still experimental in
 OpenJDK15 ?
In-Reply-To: <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>
References: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>
 <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>
Message-ID: <4477e1a4-2b33-362e-2ef9-5d95fbe27ff2@free.fr>

On 16/09/2020 18:36, Holger Hoffst?tte wrote:
> On 2020-09-16 18:13, thevenet.fred at free.fr wrote:
>> I've been using ShenandoahGC since the release of OpenJDK 13 (as
>> provided by Azul[1]) to benefit from its "
>> ShenandoahGCHeuristics=compact" option which is a good fit for my
>> need (a generally small, non critical, client application with
>> transient needs for a larger heap).
>>
>> More specifically, I use the following parameters: -XX:
>> +UnlockExperimentalVMOptions -XX:+UseShenandoahGC
>> -XX:ShenandoahGCHeuristics=compact
>> -XX:ShenandoahAllocationThreshold=20
>
> Where did you find my options? :D
>
>> Starting with 15, I was under the impression I no longer needed to
>> set +UnlockExperimentalVMOptions, to use the above options. Yet
>> starting a JVM with without unlocking experimental options yields the
>> following error: "Error: VM option 'ShenandoahAllocationThreshold' is
>> experimental and must be enabled via
>> -XX:+UnlockExperimentalVMOptions."
>>
>> If I simply omit "ShenandoahAllocationThreshold", then the JVM
>> starts.
>>
>> Is this the expected behaviour? If so, is there a list of Shenandoah-
>> specific options that are still experimental somewhere?
>
> I don't think it's the expected behaviour (as of 15) and can confirm that
> I get the same with the AdoptOpenJDK 15 binary that I'm currently 
> testing,
> so it's probably just an oversight/bug when parsing the arguments and
> checking their status. AFAIK there is nothing experimental about the
> ShenandoahAllocationThreshold flag itself or compact mode.
>
> cheers
> Holger

Thanks, that's what I suspected as well.

Should I open an issue somewhere? Btw, are Shenandoah issues tracked in 
the JBS? or somewhere else? Thanks.

-- Fred




From zgu at redhat.com  Wed Sep 16 18:39:55 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 16 Sep 2020 14:39:55 -0400
Subject: Is option "ShenandoahAllocationThreshold" still experimental in
 OpenJDK15 ?
In-Reply-To: <4477e1a4-2b33-362e-2ef9-5d95fbe27ff2@free.fr>
References: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>
 <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>
 <4477e1a4-2b33-362e-2ef9-5d95fbe27ff2@free.fr>
Message-ID: <a8950b93-8318-6d7a-caaa-de069e4ed7df@redhat.com>

Hi Frederic and Holger,

>>>
>>> More specifically, I use the following parameters: -XX:
>>> +UnlockExperimentalVMOptions -XX:+UseShenandoahGC
>>> -XX:ShenandoahGCHeuristics=compact
>>> -XX:ShenandoahAllocationThreshold=20
>>
>> Where did you find my options? :D
>>
>>> Starting with 15, I was under the impression I no longer needed to
>>> set +UnlockExperimentalVMOptions, to use the above options. Yet
>>> starting a JVM with without unlocking experimental options yields the
>>> following error: "Error: VM option 'ShenandoahAllocationThreshold' is
>>> experimental and must be enabled via
>>> -XX:+UnlockExperimentalVMOptions."
>>>
>>> If I simply omit "ShenandoahAllocationThreshold", then the JVM
>>> starts.
>>>

Although UseShenandoahGC is no longer an experimental option, 
ShenandoahAllocationThreshold remains, so you still need 
+UnlockExperimentalVMOptions for ShenandoahAllocationThreshold option.

It is the expected behavior.

Thanks,

-Zhengyu

>>> Is this the expected behaviour? If so, is there a list of Shenandoah-
>>> specific options that are still experimental somewhere?
>>
>> I don't think it's the expected behaviour (as of 15) and can confirm that
>> I get the same with the AdoptOpenJDK 15 binary that I'm currently 
>> testing,
>> so it's probably just an oversight/bug when parsing the arguments and
>> checking their status. AFAIK there is nothing experimental about the
>> ShenandoahAllocationThreshold flag itself or compact mode.
>>
>> cheers
>> Holger
> 
> Thanks, that's what I suspected as well.
> 
> Should I open an issue somewhere? Btw, are Shenandoah issues tracked in 
> the JBS? or somewhere else? Thanks.
> 
> -- Fred
> 
> 
> 


From thevenet.fred at free.fr  Wed Sep 16 18:59:11 2020
From: thevenet.fred at free.fr (Frederic Thevenet)
Date: Wed, 16 Sep 2020 20:59:11 +0200
Subject: Is option "ShenandoahAllocationThreshold" still experimental in
 OpenJDK15 ?
In-Reply-To: <a8950b93-8318-6d7a-caaa-de069e4ed7df@redhat.com>
References: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>
 <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>
 <4477e1a4-2b33-362e-2ef9-5d95fbe27ff2@free.fr>
 <a8950b93-8318-6d7a-caaa-de069e4ed7df@redhat.com>
Message-ID: <65d8db52-2067-db33-b310-f26a5dcd3f2d@free.fr>

On 16/09/2020 20:39, Zhengyu Gu wrote:
> Hi Frederic and Holger,
>
>>>> Starting with 15, I was under the impression I no longer needed to
>>>> set +UnlockExperimentalVMOptions, to use the above options. Yet
>>>> starting a JVM with without unlocking experimental options yields the
>>>> following error: "Error: VM option 'ShenandoahAllocationThreshold' is
>>>> experimental and must be enabled via
>>>> -XX:+UnlockExperimentalVMOptions."
>>>>
>>>> If I simply omit "ShenandoahAllocationThreshold", then the JVM
>>>> starts.
>>>>
>
> Although UseShenandoahGC is no longer an experimental option, 
> ShenandoahAllocationThreshold remains, so you still need 
> +UnlockExperimentalVMOptions for ShenandoahAllocationThreshold option.
>
> It is the expected behavior.
>
> Thanks,
>
> -Zhengyu

Thank you for the clarification.

I think it would be helpful to have a list of features that remain 
experimental in jdk15 on the OpenJDK Wiki page for Shenandoah [1] .

Thanks,

-- Fred

[1] https://wiki.openjdk.java.net/display/shenandoah/Main



From rkennke at redhat.com  Wed Sep 16 19:19:18 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 16 Sep 2020 21:19:18 +0200
Subject: Is option "ShenandoahAllocationThreshold" still experimental in
 OpenJDK15 ?
In-Reply-To: <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>
References: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>
 <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>
Message-ID: <bd0011feb70eeef642f814c91ced67d920aec510.camel@redhat.com>

Am Mittwoch, den 16.09.2020, 18:36 +0200 schrieb Holger Hoffst?tte:
> On 2020-09-16 18:13, thevenet.fred at free.fr wrote:
> > I've been using ShenandoahGC since the release of OpenJDK 13 (as
> > provided by Azul[1]) to benefit from its "
> > ShenandoahGCHeuristics=compact" option which is a good fit for my
> > need (a generally small, non critical, client application with
> > transient needs for a larger heap).
> > 
> > More specifically, I use the following parameters: -XX:
> > +UnlockExperimentalVMOptions -XX:+UseShenandoahGC
> > -XX:ShenandoahGCHeuristics=compact
> > -XX:ShenandoahAllocationThreshold=20
> 
> Where did you find my options? :D
> 
> > Starting with 15, I was under the impression I no longer needed to
> > set +UnlockExperimentalVMOptions, to use the above options. Yet
> > starting a JVM with without unlocking experimental options yields
> > the
> > following error: "Error: VM option 'ShenandoahAllocationThreshold'
> > is
> > experimental and must be enabled via
> > -XX:+UnlockExperimentalVMOptions."
> > 
> > If I simply omit "ShenandoahAllocationThreshold", then the JVM
> > starts.
> > 
> > Is this the expected behaviour? If so, is there a list of
> > Shenandoah-
> > specific options that are still experimental somewhere?
> 
> I don't think it's the expected behaviour (as of 15) and can confirm
> that
> I get the same with the AdoptOpenJDK 15 binary that I'm currently
> testing,
> so it's probably just an oversight/bug when parsing the arguments and
> checking their status. AFAIK there is nothing experimental about the
> ShenandoahAllocationThreshold flag itself or compact mode.

It is expected. 'Experimental' with regards to tuning flags means that
we might want to change our minds (e.g. renaming them, or come up with
different tuning/heuristics parameters, etc). It doesn't mean that they
are unstable or that you shouldn't use them in production. It just
means that they might require some adjustments when upgrading your JDK
to a later version. We left most of the tuning flags as experimental
for now.

Does that make sense?

Thanks,
Roman


From thevenet.fred at free.fr  Wed Sep 16 20:01:54 2020
From: thevenet.fred at free.fr (Frederic Thevenet)
Date: Wed, 16 Sep 2020 22:01:54 +0200
Subject: Is option "ShenandoahAllocationThreshold" still experimental in
 OpenJDK15 ?
In-Reply-To: <bd0011feb70eeef642f814c91ced67d920aec510.camel@redhat.com>
References: <1856153728.283462952.1600272794623.JavaMail.zimbra@free.fr>
 <0d5f0dad-73a3-8e53-df28-f92647120e58@applied-asynchrony.com>
 <bd0011feb70eeef642f814c91ced67d920aec510.camel@redhat.com>
Message-ID: <498e55d5-f754-046e-ddf7-9dfa10b2c384@free.fr>

Hi,

> It is expected. 'Experimental' with regards to tuning flags means that
> we might want to change our minds (e.g. renaming them, or come up with
> different tuning/heuristics parameters, etc). It doesn't mean that they
> are unstable or that you shouldn't use them in production. It just
> means that they might require some adjustments when upgrading your JDK
> to a later version. We left most of the tuning flags as experimental
> for now.
>
> Does that make sense?

It's perfectly fine by me; as I mentioned previously, I've been using 
these options (with the experimental flag) since 13 and they've served 
me very well so far, so I doesn't bother me that some of them are still 
marked as experimental.

It did, however, come as a surprise (because I wrongly assumed that 
because UseShenandoahGC itself no longer required the flag, that would 
be true for all of the existing flags) and since I saw nothing specific 
about that particular option on the wiki page, I suspected it might be 
unintentional.

Anyway, thanks for clearing that out.

-- Fred.


From dholmes at openjdk.java.net  Thu Sep 17 00:40:40 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Sep 2020 00:40:40 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]
In-Reply-To: <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
Message-ID: <V-fa8D8Ca9kTvZJmKZgj1R4NX6nz1oqXJwMUEdPRYok=.dfb3f8b8-a99e-4e50-a7b1-244139eafcbc@github.com>

On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes/deletions to address kimbarrett and sspitsyn CR comments.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From kbarrett at openjdk.java.net  Thu Sep 17 04:15:19 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 17 Sep 2020 04:15:19 GMT
Subject: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]
In-Reply-To: <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
 <xeZEMQCPkkoQkcmDcqkvoVjt3pvyvuyJF2UarJ5VQVg=.8bb49cb1-c267-4595-a5e8-b754ebdf5965@github.com>
Message-ID: <g9zcBpMJ9MCt9CWkZvIYif7gsYsbSLKGrVK-Euf8EEY=.d98aca83-3490-4145-8f40-ce5304f69677@github.com>

On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This RFE is to migrate the following field to OopStorage:
>> 
>> class ObjectMonitor {
>> <snip>
>>   void* volatile _object; // backward object pointer - strong root
>> 
>> Unlike the previous patches in this series, there are a lot of collateral
>> changes so this is not a trivial review. Sorry for the tedious parts of
>> the review. Since Erik and I are both contributors to this patch, we
>> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
>> 
>> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
>> along with JDK-8252980 and JDK-8252981. I also ran it through my
>> inflation stress kit for 48 hours on my Linux-X64 machine.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes/deletions to address kimbarrett and sspitsyn CR comments.

Marked as reviewed by kbarrett (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From iklam at openjdk.java.net  Thu Sep 17 17:57:21 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Sep 2020 17:57:21 GMT
Subject: RFR: 8253271: vm_version_x86.hpp should not include
 globals_extension.hpp [v2]
In-Reply-To: <XiDw5uwmHOyrXvHK95vLReSpbkqp7nri1SnvS-QhU1Q=.10e194ed-3e5f-4cd4-bb49-c8dafe9dbd31@github.com>
References: <XiDw5uwmHOyrXvHK95vLReSpbkqp7nri1SnvS-QhU1Q=.10e194ed-3e5f-4cd4-bb49-c8dafe9dbd31@github.com>
Message-ID: <Qz_0qZ0gzL9a9J5kSUkMlqYGdD1JMdMY6YpcZB6bceE=.b3a96fed-f005-4018-b30c-bd91c176a969@github.com>

> [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30)
> is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily
> includes globals_extension.hpp.  Removing this dependency reduces the number of cpp files that include
> globals_extension.hpp from 814 to 67.
> I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include  globals_extension.hpp.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  added more missing includes found by CI testing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/217/files
  - new: https://git.openjdk.java.net/jdk/pull/217/files/a5a2f03e..ce1508af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=00-01

  Stats: 19 lines in 17 files changed: 17 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/217.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/217/head:pull/217

PR: https://git.openjdk.java.net/jdk/pull/217

From iklam at openjdk.java.net  Thu Sep 17 19:59:11 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Sep 2020 19:59:11 GMT
Subject: RFR: 8253271: vm_version_x86.hpp should not include
 globals_extension.hpp [v2]
In-Reply-To: <bMnZ3vl2aZokLQjFq3AiLwN45Yvbd6r_Nw7zEKr0LPQ=.c21b6e1f-c9aa-47c7-a768-b4c2728d8a7f@github.com>
References: <XiDw5uwmHOyrXvHK95vLReSpbkqp7nri1SnvS-QhU1Q=.10e194ed-3e5f-4cd4-bb49-c8dafe9dbd31@github.com>
 <bMnZ3vl2aZokLQjFq3AiLwN45Yvbd6r_Nw7zEKr0LPQ=.c21b6e1f-c9aa-47c7-a768-b4c2728d8a7f@github.com>
Message-ID: <9656Nspmj41pw2RoSYiuIvZMD4Oa7uDvRA_1BfbVffw=.f5ba8275-315a-46d7-905b-bdd4f2d425e7@github.com>

On Thu, 17 Sep 2020 06:28:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added more missing includes found by CI testing
>
> Looks good - and trivial assuming all builds are good.

[ce1508a](https://github.com/openjdk/jdk/pull/217/commits/ce1508afeb9089bfe5e276eb06de34b9bfe0459a) passed tiers1/2 in
our CI pipeline. I also tested with a local build with shenandoah enabled.

-------------

PR: https://git.openjdk.java.net/jdk/pull/217

From iklam at openjdk.java.net  Thu Sep 17 21:35:28 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Sep 2020 21:35:28 GMT
Subject: Integrated: 8253271: vm_version_x86.hpp should not include
 globals_extension.hpp
In-Reply-To: <XiDw5uwmHOyrXvHK95vLReSpbkqp7nri1SnvS-QhU1Q=.10e194ed-3e5f-4cd4-bb49-c8dafe9dbd31@github.com>
References: <XiDw5uwmHOyrXvHK95vLReSpbkqp7nri1SnvS-QhU1Q=.10e194ed-3e5f-4cd4-bb49-c8dafe9dbd31@github.com>
Message-ID: <A10borTeCJmoZvNWprBN89MNLr-c7qbIu5Ao05lUy5Y=.fc12d021-8743-4a4d-ae55-2baef6007c30@github.com>

On Thu, 17 Sep 2020 05:05:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30)
> is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily
> includes globals_extension.hpp.  Removing this dependency reduces the number of cpp files that include
> globals_extension.hpp from 814 to 67.
> I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include  globals_extension.hpp.

This pull request has now been integrated.

Changeset: 0a1dc50f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a1dc50f
Stats:     48 lines in 43 files changed: 3 ins; 41 del; 4 mod

8253271: vm_version_x86.hpp should not include globals_extension.hpp

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/217

From iklam at openjdk.java.net  Thu Sep 17 21:35:26 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Sep 2020 21:35:26 GMT
Subject: RFR: 8253271: vm_version_x86.hpp should not include
 globals_extension.hpp [v3]
In-Reply-To: <XiDw5uwmHOyrXvHK95vLReSpbkqp7nri1SnvS-QhU1Q=.10e194ed-3e5f-4cd4-bb49-c8dafe9dbd31@github.com>
References: <XiDw5uwmHOyrXvHK95vLReSpbkqp7nri1SnvS-QhU1Q=.10e194ed-3e5f-4cd4-bb49-c8dafe9dbd31@github.com>
Message-ID: <DK35mH_FzjVNavOA2EzovryeIGAaoB5xuJ2_R-bs3Do=.62da5024-afb3-41de-a7f1-ee08a5df4f6e@github.com>

> [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30)
> is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily
> includes globals_extension.hpp.  Removing this dependency reduces the number of cpp files that include
> globals_extension.hpp from 814 to 67.
> I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include  globals_extension.hpp.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last
revision:

 - Merge branch 'master' into 8253271-remove-globals-extensions-from-vm-version-x86-hpp
 - added more missing includes found by CI testing
 - 8253271: vm_version_x86.hpp should not include globals_extension.hpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/217/files
  - new: https://git.openjdk.java.net/jdk/pull/217/files/ce1508af..28e894f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=01-02

  Stats: 288 lines in 32 files changed: 131 ins; 29 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/217.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/217/head:pull/217

PR: https://git.openjdk.java.net/jdk/pull/217

From gnu.andrew at redhat.com  Fri Sep 18 03:45:19 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 18 Sep 2020 04:45:19 +0100
Subject: [RFR] [8u] 8u272-b08 Upstream Sync
Message-ID: <20200918034519.GA331493@stopbrexit>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/

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

Changes in aarch64-shenandoah-jdk8u272-b08:
  - JDK-8062947: Fix exception message to correctly represent LDAP connection failure
  - JDK-8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect
  - JDK-8252573: 8u: Windows build failed after 8222079 backport

Main issues of note:
None, clean merge (only one minor one line HotSpot change).

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/classes/com/sun/jndi/ldap/Connection.java             |   65 
 b/src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java |    4 
 b/src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java |   25 
 b/src/share/classes/com/sun/jndi/ldap/LdapRequest.java            |   27 
 b/test/com/sun/jndi/ldap/LdapTimeoutTest.java                     |  778 +++++-----
 b/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java          |  165 ++
 b/test/com/sun/jndi/ldap/lib/BaseLdapServer.java                  |   27 
 8 files changed, 669 insertions(+), 423 deletions(-)

diffstat for hotspot
 b/.hgtags                                |    1 +
 b/src/share/vm/compiler/disassembler.cpp |    1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

Successfully built on x86, x86_64, s390x (Zero), ppc64le,
aarch32 (Zero) & aarch64 [0].

Ok to push?

[0] https://koji.fedoraproject.org/koji/buildinfo?buildID=1612280

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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  Fri Sep 18 07:49:20 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 18 Sep 2020 09:49:20 +0200
Subject: [RFR] [8u] 8u272-b08 Upstream Sync
In-Reply-To: <20200918034519.GA331493@stopbrexit>
References: <20200918034519.GA331493@stopbrexit>
Message-ID: <34aa845e-be4a-9f56-63b2-620a683bfbf4@redhat.com>

On 9/18/20 5:45 AM, Andrew Hughes wrote:
> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/
> 
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/jaxws/merge.changeset

Look trivially good.

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

Looks good.

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

Look trivially good.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From shade at openjdk.java.net  Fri Sep 18 08:16:38 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 18 Sep 2020 08:16:38 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
Message-ID: <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>

On Sat, 12 Sep 2020 00:17:58 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> - enable parallel heap inspecton for ShenandoahHeap
>>   - preliminary evaluation:
>>     Time of jmap histo on (8GB heap with 4GB objects)
>>     * before: 5.186s
>>     * after : 1.698s
>
> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
> will show differences compared to the previous content of the PR. The pull request contains one new commit since the
> last revision:
>   8252104: parallel heap inspection for ShenandoahHeap
>   
>     - enable parallel heap inspecton for ShenandoahHeap
>     - preliminary evaluation:
>       Time of jmap histo on (8GB heap with 4GB objects)
>       * before: 5.186s
>       * after : 1.698s

Sorry for the delay! I think there is a concurrency bug in using `Stack` from multiple threads. Plus, there are a bunch
of stylistic nits.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1314:

> 1312:
> 1313:   Stack<oop,mtGC> oop_stack;
> 1314:   // root marking

This needs to be close to `scan_roots_for_iteration` call, and the comment should match the style: "// Seed the stack
with root scan".

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1333:

> 1331:
> 1332: bool ShenandoahHeap::prepare_aux_bitmap_for_iteration() {
> 1333:     assert(SafepointSynchronize::is_at_safepoint(), "safe iteration is only available during safepoints");

Indenting should be 2 spaces in this method.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1346:

> 1344:
> 1345: void ShenandoahHeap::scan_roots_for_iteration(Stack<oop, mtGC>* oop_stack, ObjectIterateScanRootClosure* oops) {
> 1346:     // Process GC roots according to current GC cycle.

Indenting should be 2 spaces in this method.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1341:

> 1339:
> 1340:     // Reset bitmap
> 1341:     _aux_bit_map.clear();

Wait a sec, we have just uncommitted the aux bitmap, so `clear()` is bound to crash?

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1380:

> 1378:
> 1379:       assert(oopDesc::is_oop(obj), "must be a valid oop");
> 1380:       // parallel mark

No need for this comment, it is obvious from the context.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1470:

> 1468:     for (uint j = 0; j < roots_num; j++) {
> 1469:       uint stack_id = j % _num_workers;
> 1470:       oop obj = _roots_stack.pop();

I am not sure we can `pop()` the stack from multiple threads without any sort of synchronization. It might be better to
just walk the same roots from multiple threads, and then let the bitmap help us figure out if we have visited the root
already. See how `ShenandoahVerifierReachableTask` does it?

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1422:

> 1420:     // Procssing roots
> 1421:     _heap->scan_roots_for_iteration(&_roots_stack, &oops);
> 1422:     // prepare worker stacks

All three comments look excessive to me? Also, typo in "Procssing". I'd say:

    _init_ready = _heap->prepare_aux_bitmap_for_iteration();
    if (!_init_ready) {
      return;
    }

    ObjectIterateScanRootClosure oops(_aux_bit_map, &_roots_stack);
    _heap->scan_roots_for_iteration(&_roots_stack, &oops);

    _init_ready = prepare_worker_queues();

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1405:

> 1403:   MarkBitMap*                  _aux_bit_map;
> 1404:   ShenandoahHeap*              _heap;
> 1405:   Stack<oop, mtGC>             _roots_stack; // global roots stack

I don't think we can share the stack here. See the comment near `pop()` below.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1450:

> 1448:
> 1449: private:
> 1450:   // divide global root_stack into worker queues.

Capitalize: "// Divide"

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1453:

> 1451:   bool prepare_worker_queues() {
> 1452:     _task_queues = new ShenandoahObjToScanQueueSet((int) _num_workers);
> 1453:     // initialize queue for every workers

`// Initialize queue for every worker` -- singular.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1465:

> 1463:       return false;
> 1464:     }
> 1465:     // assume that object referencing distribution is related with

This comment is better to merge with the previous one. So that we have:

    // Distribute roots among the workers. Assume that object referencing distribution
    // is related with/ root kind, use round-robin to make every worker have same chance
    // to process every kind of roots
    size_t roots_num = _roots_stack.size();
    if (roots_num == 0) {
      // no work to do.
      return false;
    }

    for (uint j = 0; j < roots_num; j++) {
      uint stack_id = j % _num_workers;
      oop obj = _roots_stack.pop();
      ...

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1484:

> 1482:     ShenandoahObjToScanQueue* q = queue_set->queue(worker_id);
> 1483:     assert(q != NULL, "object iterate queue must not be NULL");
> 1484:     // Task in queue

Unnecessary comment, just have a new line here.

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 41:

> 39: #include "utilities/globalDefinitions.hpp"
> 40: #include "utilities/stack.hpp"
> 41:

Excess new line

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 560:

> 558:   // Used for native heap walkers: heap dumpers, mostly
> 559:   void object_iterate(ObjectClosure* cl);
> 560:   // parallel heap iteration support

Capitalize `// Parallel`

-------------

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/67

From lzang at openjdk.java.net  Fri Sep 18 09:43:29 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 18 Sep 2020 09:43:29 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
 <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>
Message-ID: <_QLwcdW87yyBv6JAH52DN0RmB_n86MSkLPJAYi0TNfY=.d57c7001-4a8b-4095-968a-9cdaf5565daf@github.com>

On Fri, 18 Sep 2020 08:03:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1470:
> 
>> 1468:     for (uint j = 0; j < roots_num; j++) {
>> 1469:       uint stack_id = j % _num_workers;
>> 1470:       oop obj = _roots_stack.pop();
> 
> I am not sure we can `pop()` the stack from multiple threads without any sort of synchronization. It might be better to
> just walk the same roots from multiple threads, and then let the bitmap help us figure out if we have visited the root
> already. See how `ShenandoahVerifierReachableTask` does it?

Hi @shipilev,
Thanks for your effort for reviewing this change!
The method prepare_worker_queue() here is invoked in the constructor of ShenandoahParallelObjectIterator, which is
designed to run in single thread.  The logic of using ParallelObjectIterator is as follows: (refer to code in
hotspot/share/memory/heapInspection.cpp)
 -  create instance of ParallelObjectIterator in shenandoahHeap:
      ParallelObjectIterator* poi = Universe::heap()->parallel_object_iterator(gang->active_workers())
 - create heap iteration task and run (invoke ParallelObjectIterator's method object_iterator())
     ParHeapInspectTask task(**poi**, cit, filter);
     // Run task with the active workers.
     gang->run_task(&task);
=======
So the ShenandoahParallelObjectIterator iterate all roots in the single thread, collecting all roots in the
roots_stack, then prepare the queues for every workers.  -- processed in constructor. And the workers start their
processing from their queue, and then iterate all reachable objects. -- processed in work(uint worker_id)

I have checked that ShenandoahVerifierReachableTask supports iterating roots parallelly, I didn't choose that way
because I want to make every workers to start with nearly the same number of roots in their queue, hope it could help
on inital work load balance.

Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From shade at openjdk.java.net  Fri Sep 18 09:46:28 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 18 Sep 2020 09:46:28 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <_QLwcdW87yyBv6JAH52DN0RmB_n86MSkLPJAYi0TNfY=.d57c7001-4a8b-4095-968a-9cdaf5565daf@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
 <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>
 <_QLwcdW87yyBv6JAH52DN0RmB_n86MSkLPJAYi0TNfY=.d57c7001-4a8b-4095-968a-9cdaf5565daf@github.com>
Message-ID: <qju-2qlN34-cxPFw5C_ceYu-kkFfps187huqoVp0CTI=.0a0a6656-f29c-44aa-94de-1bb0d63f5eee@github.com>

On Fri, 18 Sep 2020 09:40:12 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1470:
>> 
>>> 1468:     for (uint j = 0; j < roots_num; j++) {
>>> 1469:       uint stack_id = j % _num_workers;
>>> 1470:       oop obj = _roots_stack.pop();
>> 
>> I am not sure we can `pop()` the stack from multiple threads without any sort of synchronization. It might be better to
>> just walk the same roots from multiple threads, and then let the bitmap help us figure out if we have visited the root
>> already. See how `ShenandoahVerifierReachableTask` does it?
>
> Hi @shipilev,
> Thanks for your effort for reviewing this change!
> The method prepare_worker_queue() here is invoked in the constructor of ShenandoahParallelObjectIterator, which is
> designed to run in single thread.  The logic of using ParallelObjectIterator is as follows: (refer to code in
> hotspot/share/memory/heapInspection.cpp)
>  -  create instance of ParallelObjectIterator in shenandoahHeap:
>       ParallelObjectIterator* poi = Universe::heap()->parallel_object_iterator(gang->active_workers())
>  - create heap iteration task and run (invoke ParallelObjectIterator's method object_iterator())
>      ParHeapInspectTask task(**poi**, cit, filter);
>      // Run task with the active workers.
>      gang->run_task(&task);
> =======
> So the ShenandoahParallelObjectIterator iterate all roots in the single thread, collecting all roots in the
> roots_stack, then prepare the queues for every workers.  -- processed in constructor. And the workers start their
> processing from their queue, and then iterate all reachable objects. -- processed in work(uint worker_id)
> I have checked that ShenandoahVerifierReachableTask supports iterating roots parallelly, I didn't choose that way
> because I want to make every workers to start with nearly the same number of roots in their queue, hope it could help
> on inital work load balance.  Lin

Ah! I missed that part. I thought stack is used by the actual parallel workers. Nevermind my correctness comment then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From mbeckwit at openjdk.java.net  Fri Sep 18 10:14:22 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Fri, 18 Sep 2020 10:14:22 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
Message-ID: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>

This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
 
Changes since then:
* We've improved the write barrier as suggested by Andrew [1]
* The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
  will be required for the upcoming macOS+Aarch64 [2] port as well.
* We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
  Windows-specific CPU feature detection on top of it.

[1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
[2] https://openjdk.java.net/jeps/8251280

-------------

Commit messages:
 - 8248787: G1: Workaround MSVC bug
 - 8248670: Windows: Exception handling support on AArch64
 - 8248660: AArch64: Make _clear_cache and _nop portable
 - 8248659: AArch64: Extend CPU Feature detection
 - 8248656: Add Windows AArch64 platform support code
 - 8248498: Add build system support for Windows AArch64
 - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__
 - 8248663: AArch64: Avoid existing macros/keywords of MSVC
 - 8248676: AArch64: Add workaround for LITable constructor
 - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests)
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/68da63dc...26e4af3a

Changes: https://git.openjdk.java.net/jdk/pull/212/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248238
  Stats: 4230 lines in 69 files changed: 2406 ins; 273 del; 1551 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From erikj at openjdk.java.net  Fri Sep 18 13:35:34 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 18 Sep 2020 13:35:34 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>

On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Build changes look good to me. I will take this branch for a spin.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From erikj at openjdk.java.net  Fri Sep 18 15:37:26 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 18 Sep 2020 15:37:26 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
In-Reply-To: <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>
Message-ID: <BtXRWhdTVMJd1UyIAZTtUbCxnAfM20wCvbigZvdlbDk=.87224bc2-3fe9-4790-9602-f7e8c264f31b@github.com>

On Fri, 18 Sep 2020 13:33:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Build changes look good to me. I will take this branch for a spin.

Our linux-aarch64 build fails with this:
cc: error: unrecognized command line option '-std=c++14'
when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch

I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing,
and if so, how are you addressing it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From gnu.andrew at redhat.com  Fri Sep 18 15:46:36 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 18 Sep 2020 16:46:36 +0100
Subject: [RFR] [8u] 8u272-b08 Upstream Sync
In-Reply-To: <34aa845e-be4a-9f56-63b2-620a683bfbf4@redhat.com>
References: <20200918034519.GA331493@stopbrexit>
 <34aa845e-be4a-9f56-63b2-620a683bfbf4@redhat.com>
Message-ID: <20200918154636.GA371187@stopbrexit>

On 09:49 Fri 18 Sep     , Aleksey Shipilev wrote:
> On 9/18/20 5:45 AM, Andrew Hughes wrote:
> > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/
> > 
> > Merge changesets:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/jaxws/merge.changeset
> 
> Look trivially good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/jdk/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/hotspot/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b08/root/merge.changeset
> 
> Look trivially good.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks. Pushed.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 zgu at openjdk.java.net  Fri Sep 18 16:09:11 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 18 Sep 2020 16:09:11 GMT
Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag	
Message-ID: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>

ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check
too.

-------------

Commit messages:
 - Honor ShenandoahSelfFixing flag in runtime barrier
 - Tighten recusive reserveration handling
 - Fix trailing whitespace
 - Restore assertion
 - JDK-8252921
 - JDK-8252921

Changes: https://git.openjdk.java.net/jdk/pull/254/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=254&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253361
  Stats: 34 lines in 4 files changed: 18 ins; 13 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/254/head:pull/254

PR: https://git.openjdk.java.net/jdk/pull/254

From rkennke at openjdk.java.net  Fri Sep 18 16:17:29 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 18 Sep 2020 16:17:29 GMT
Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag	
In-Reply-To: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>
References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>
Message-ID: <Fh6V9h0h1-ps1ESZ0Jr3FDUveAVJ6u25U2P82XWjt9U=.29457161-4d79-4f17-9a04-4c378f768c5d@github.com>

On Fri, 18 Sep 2020 16:03:20 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check
> too.

There seems to be a lot of unrelated changes in that patch, all that thread/NMT stuff...

-------------

Changes requested by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/254

From zgu at openjdk.java.net  Fri Sep 18 17:08:33 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 18 Sep 2020 17:08:33 GMT
Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag	 [v2]
In-Reply-To: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>
References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>
Message-ID: <UeUsem-Xz0EE1EV6CTtnyuFWhGh91rZuVffM-kUQ-zs=.b1b48496-31eb-4aac-bfbd-39dd3d585f61@github.com>

> ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check
> too.

Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since
the last revision:

 - Merge branch 'JDK-8253361' of github.com:zhengyu123/jdk into JDK-8253361
 - Honor ShenandoahSelfFixing flag in runtime barrier
 - Tighten recusive reserveration handling
 - Fix trailing whitespace
 - Restore assertion
 - JDK-8252921
 - JDK-8252921
 - Honor ShenandoahSelfFixing flag in runtime barrier

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/254/files
  - new: https://git.openjdk.java.net/jdk/pull/254/files/739124ff..953e9173

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=254&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=254&range=00-01

  Stats: 7549 lines in 261 files changed: 3641 ins; 3125 del; 783 mod
  Patch: https://git.openjdk.java.net/jdk/pull/254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/254/head:pull/254

PR: https://git.openjdk.java.net/jdk/pull/254

From burban at openjdk.java.net  Fri Sep 18 18:41:13 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Fri, 18 Sep 2020 18:41:13 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
In-Reply-To: <BtXRWhdTVMJd1UyIAZTtUbCxnAfM20wCvbigZvdlbDk=.87224bc2-3fe9-4790-9602-f7e8c264f31b@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>
 <BtXRWhdTVMJd1UyIAZTtUbCxnAfM20wCvbigZvdlbDk=.87224bc2-3fe9-4790-9602-f7e8c264f31b@github.com>
Message-ID: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com>

On Fri, 18 Sep 2020 15:34:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Build changes look good to me. I will take this branch for a spin.
>
> Our linux-aarch64 build fails with this:
> cc: error: unrecognized command line option '-std=c++14'
> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch
> 
> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing,
> and if so, how are you addressing it?

Hey @erikj79, thank you so much for giving it a try!

> Our linux-aarch64 build fails with this:
> cc: error: unrecognized command line option '-std=c++14'
> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch

Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on
such a system: $ cat /etc/issue
Ubuntu 19.10 \n \l
$ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg
$ make clean CONF=linux-aarch64-server-release
$ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release
$ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64
    java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk
    os.arch = aarch64
    sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib
--------------------------------------------------------
> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing,
> and if so, how are you addressing it?

Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on
Windows targets (as it hasn't been a thing so far). We use a workaround internally
https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on
build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From zgu at openjdk.java.net  Fri Sep 18 19:07:50 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 18 Sep 2020 19:07:50 GMT
Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag	 [v2]
In-Reply-To: <Fh6V9h0h1-ps1ESZ0Jr3FDUveAVJ6u25U2P82XWjt9U=.29457161-4d79-4f17-9a04-4c378f768c5d@github.com>
References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>
 <Fh6V9h0h1-ps1ESZ0Jr3FDUveAVJ6u25U2P82XWjt9U=.29457161-4d79-4f17-9a04-4c378f768c5d@github.com>
Message-ID: <drgqlj36n7WnAHJwiwqtpKXA7BalodGijG2rZzCjL7g=.6d92a692-c638-4dbb-a86b-af547d72476d@github.com>

On Fri, 18 Sep 2020 16:14:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since
>> the last revision:
>>  - Merge branch 'JDK-8253361' of github.com:zhengyu123/jdk into JDK-8253361
>>  - Honor ShenandoahSelfFixing flag in runtime barrier
>>  - Tighten recusive reserveration handling
>>  - Fix trailing whitespace
>>  - Restore assertion
>>  - JDK-8252921
>>  - JDK-8252921
>>  - Honor ShenandoahSelfFixing flag in runtime barrier
>
> There seems to be a lot of unrelated changes in that patch, all that thread/NMT stuff...

Messed up with branching, will re-do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/254

From zgu at openjdk.java.net  Fri Sep 18 19:07:50 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 18 Sep 2020 19:07:50 GMT
Subject: Withdrawn: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag	
In-Reply-To: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>
References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com>
Message-ID: <QFAt9qL9dlkxw0ujzYDNus-_W0iUS157JtJ_-NMJ4ic=.2015004e-e330-45b7-acb4-2afe720b78c3@github.com>

On Fri, 18 Sep 2020 16:03:20 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check
> too.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/254

From zgu at openjdk.java.net  Fri Sep 18 19:37:18 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 18 Sep 2020 19:37:18 GMT
Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag
Message-ID: <64xxQ12K5x3NrMGTAt8prD6KQCYbnTlQvqhJ5R3FXfY=.87308a79-def2-47d8-afc5-fb5fa61cbb54@github.com>

ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check
too.

-------------

Commit messages:
 - 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag

Changes: https://git.openjdk.java.net/jdk/pull/257/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=257&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253361
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/257.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/257/head:pull/257

PR: https://git.openjdk.java.net/jdk/pull/257

From rkennke at openjdk.java.net  Fri Sep 18 19:44:32 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 18 Sep 2020 19:44:32 GMT
Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag
In-Reply-To: <64xxQ12K5x3NrMGTAt8prD6KQCYbnTlQvqhJ5R3FXfY=.87308a79-def2-47d8-afc5-fb5fa61cbb54@github.com>
References: <64xxQ12K5x3NrMGTAt8prD6KQCYbnTlQvqhJ5R3FXfY=.87308a79-def2-47d8-afc5-fb5fa61cbb54@github.com>
Message-ID: <n9EsVEjP8BUUqyPiwrprEqyqOyEH_eqQI6JcGLNul40=.5f52878e-f012-4dd1-aeb1-7cf38fb9c87b@github.com>

On Fri, 18 Sep 2020 19:31:07 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check
> too.

Looks good to me!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/257

From zgu at openjdk.java.net  Fri Sep 18 20:19:37 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 18 Sep 2020 20:19:37 GMT
Subject: Integrated: 8253361: Shenandoah: runtime barrier does not honor
 ShenandoahSelfFixing flag
In-Reply-To: <64xxQ12K5x3NrMGTAt8prD6KQCYbnTlQvqhJ5R3FXfY=.87308a79-def2-47d8-afc5-fb5fa61cbb54@github.com>
References: <64xxQ12K5x3NrMGTAt8prD6KQCYbnTlQvqhJ5R3FXfY=.87308a79-def2-47d8-afc5-fb5fa61cbb54@github.com>
Message-ID: <Mp_Oy1jzAiQcdTze-uX4QWD2cL1hitHWeimhiaQ5uhI=.c96dbc18-1245-4a02-8bf2-d7ee85606995@github.com>

On Fri, 18 Sep 2020 19:31:07 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check
> too.

This pull request has now been integrated.

Changeset: d35b1179
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d35b1179
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag

Reviewed-by: rkennke

-------------

PR: https://git.openjdk.java.net/jdk/pull/257

From erikj at openjdk.java.net  Fri Sep 18 20:37:45 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 18 Sep 2020 20:37:45 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <axvLamk-3k-CVBfcyN0Nc59o1619WwmDwm4wweMX2M4=.1fa21044-7b40-4107-abb3-ccd40b0fd923@github.com>

On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

make/autoconf/toolchain.m4 line 902:

> 900:           BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin"
> 901:         fi
> 902:         UTIL_PREPEND_TO_PATH([PATH],$BUILD_DEVKIT_TOOLCHAIN_PATH)

Here is a problem. In our linux cross compile build, we rely on the PATH being completely overwritten with the paths
from the devkit here. Otherwise the UTIL_REQUIRE_PROGS may find /usr/bin/cc before $BUILD_DEVKIT_TOOLCHAIN_PATH/gcc.

This is the reason my linux-aarch64 (cross compile) build failed. The system installed cc was too old to recognize
the -stdc=c++14 argument.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From erikj at openjdk.java.net  Fri Sep 18 20:37:45 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 18 Sep 2020 20:37:45 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
In-Reply-To: <axvLamk-3k-CVBfcyN0Nc59o1619WwmDwm4wweMX2M4=.1fa21044-7b40-4107-abb3-ccd40b0fd923@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <axvLamk-3k-CVBfcyN0Nc59o1619WwmDwm4wweMX2M4=.1fa21044-7b40-4107-abb3-ccd40b0fd923@github.com>
Message-ID: <RN3cacKvAfMGjCpxdH2mdvPJH9XwKmAIUCDtNzgFpMw=.7060b196-467f-4ae2-b527-7f5bf938ab8f@github.com>

On Fri, 18 Sep 2020 20:32:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> make/autoconf/toolchain.m4 line 902:
> 
>> 900:           BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin"
>> 901:         fi
>> 902:         UTIL_PREPEND_TO_PATH([PATH],$BUILD_DEVKIT_TOOLCHAIN_PATH)
> 
> Here is a problem. In our linux cross compile build, we rely on the PATH being completely overwritten with the paths
> from the devkit here. Otherwise the UTIL_REQUIRE_PROGS may find /usr/bin/cc before $BUILD_DEVKIT_TOOLCHAIN_PATH/gcc.
> This is the reason my linux-aarch64 (cross compile) build failed. The system installed cc was too old to recognize
> the -stdc=c++14 argument.

I assume you need the rest of the PATH on Windows.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From aph at redhat.com  Sat Sep 19 09:27:36 2020
From: aph at redhat.com (Andrew Haley)
Date: Sat, 19 Sep 2020 10:27:36 +0100
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <ac54f3ab-5b4b-854c-936a-a5ae4078fcff@redhat.com>

On 18/09/2020 11:14, Monica Beckwith wrote:

> This is a continuation of
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]

It's still wrong, I'm afraid. This is not a full barrier:

+#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel);

it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as
well. It might well be that you get the same DMB ISH instruction, but
unless you use a StoreLoad barrier here it's theoretically possible
for a compiler to reorder accesses so that a processor sees its own
stores before other processors do. (And it's confusing for the reader
too.)

Use:

+#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst);

See here:

https://en.cppreference.com/w/cpp/atomic/memory_order

memory_order_seq_cst "...plus a single total order exists in which all
threads observe all modifications in the same order (see
Sequentially-consistent ordering below)"

-- 
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 Sep 19 10:21:05 2020
From: aph at redhat.com (Andrew Haley)
Date: Sat, 19 Sep 2020 11:21:05 +0100
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <bc4dbf34-a936-d03e-b8aa-f8448f269d2b@redhat.com>

On 18/09/2020 11:14, Monica Beckwith wrote:
> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html

The diffs in assembler_aarch64.cpp are mostly spurious. Please try this.

-- 
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
-------------- next part --------------
diff --git a/src/hotspot/cpu/aarch64/aarch64-asmtest.py b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
index f5a5c6b5aee..43bac8e8142 100644
--- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
+++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
@@ -12,8 +12,11 @@ class Operand(object):
 class Register(Operand):
 
     def generate(self):
-        self.number = random.randint(0, 30)
-        return self
+        while True:
+            self.number = random.randint(0, 30)
+            # r18 is used for TLS on Windows ABI.
+            if self.number != 18:
+                return self
 
     def astr(self, prefix):
         return prefix + str(self.number)
@@ -36,8 +39,10 @@ class GeneralRegister(Register):
 class GeneralRegisterOrZr(Register):
 
     def generate(self):
-        self.number = random.randint(0, 31)
-        return self
+        while True:
+            self.number = random.randint(0, 31)
+            if self.number != 18:
+                return self
 
     def astr(self, prefix = ""):
         if (self.number == 31):
@@ -53,8 +58,10 @@ class GeneralRegisterOrZr(Register):
 
 class GeneralRegisterOrSp(Register):
     def generate(self):
-        self.number = random.randint(0, 31)
-        return self
+        while True:
+            self.number = random.randint(0, 31)
+            if self.number != 18:
+                return self
 
     def astr(self, prefix = ""):
         if (self.number == 31):
@@ -1331,7 +1338,7 @@ generate(SpecialCases, [["ccmn",   "__ ccmn(zr, zr, 3u, Assembler::LE);",
                         ["st1w",   "__ sve_st1w(z0, __ S, p1, Address(r0, 7));",         "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"],
                         ["st1b",   "__ sve_st1b(z0, __ B, p2, Address(sp, r1));",        "st1b\t{z0.b}, p2, [sp, x1]"],
                         ["st1h",   "__ sve_st1h(z0, __ H, p3, Address(sp, r8));",        "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"],
-                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r18));",       "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"],
+                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r17));",       "st1d\t{z0.d}, p4, [x0, x17, LSL #3]"],
                         ["ldr",    "__ sve_ldr(z0, Address(sp));",                       "ldr\tz0, [sp]"],
                         ["ldr",    "__ sve_ldr(z31, Address(sp, -256));",                "ldr\tz31, [sp, #-256, MUL VL]"],
                         ["str",    "__ sve_str(z8, Address(r8, 255));",                  "str\tz8, [x8, #255, MUL VL]"],

From lzang at openjdk.java.net  Mon Sep 21 02:30:21 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 21 Sep 2020 02:30:21 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
 <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>
Message-ID: <MfMym_AFoq3YeftInGQNcWdp7cv4qURLLwitlty8Ni0=.e98588b3-3758-464e-97f8-1447691b7c49@github.com>

On Fri, 18 Sep 2020 08:00:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1341:
> 
>> 1339:
>> 1340:     // Reset bitmap
>> 1341:     _aux_bit_map.clear();
> 
> Wait a sec, we have just uncommitted the aux bitmap, so `clear()` is bound to crash?

No, here the aux_bit_map.clear() is called after commit_memory(), so clear() is safe to reset the bitmap.
the uncommit_memory() was moved to reclaim_aux_bitmap_for_iteration() at line 1354

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From lzang at openjdk.java.net  Mon Sep 21 02:36:18 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 21 Sep 2020 02:36:18 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]
In-Reply-To: <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <Av0EOPVPuTgtA_YwSuicN6i9D5Ok7PCquqyj0884rJ8=.3c1ede30-0b6f-4ca9-a87a-9abe74dddfbb@github.com>
 <bUGgRNjDYdml2ptqIarJy7diMeCOrAdI5or965CdtA4=.4db9f17f-73f2-48e0-9e3f-dfff750965bf@github.com>
Message-ID: <TnThZ5IPx5w7wHYbI8qMq7bDMWK3bLCAiANP5PTR8VI=.ebf6231b-f697-4eda-85f9-52d2ada6a63f@github.com>

On Fri, 18 Sep 2020 08:13:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR.
>
> Sorry for the delay! I think there is a concurrency bug in using `Stack` from multiple threads. Plus, there are a bunch
> of stylistic nits.

Dear @shipilev,
   I have updated the patch, would you like to help review again? Thanks!

-Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From lzang at openjdk.java.net  Mon Sep 21 02:36:18 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 21 Sep 2020 02:36:18 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v4]
In-Reply-To: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
Message-ID: <pPOy9agQdCtjXRFexMi3ma_eLRergiGlweeKCDaXGUY=.8ef5a687-2966-4472-a92d-067b33c20e5a@github.com>

> - enable parallel heap inspecton for ShenandoahHeap
>   - preliminary evaluation:
>     Time of jmap histo on (8GB heap with 4GB objects)
>     * before: 5.186s
>     * after : 1.698s

Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
will show differences compared to the previous content of the PR. The pull request contains one new commit since the
last revision:

  8252104: parallel heap inspection for ShenandoahHeap
  
    - enable parallel heap inspecton for ShenandoahHeap
    - preliminary evaluation:
      Time of jmap histo on (8GB heap with 4GB objects)
      * before: 5.186s
      * after : 1.698s

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/67/files
  - new: https://git.openjdk.java.net/jdk/pull/67/files/313d6cb5..1fddea7c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=02-03

  Stats: 44 lines in 2 files changed: 6 ins; 11 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/67/head:pull/67

PR: https://git.openjdk.java.net/jdk/pull/67

From kbarrett at openjdk.java.net  Mon Sep 21 04:24:25 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 21 Sep 2020 04:24:25 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum
Message-ID: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>

Please review this change to the type narrowOop from a typedef for juint to a
scoped enum with uint32_t as the representation type.  This provides stronger
type checking when using this type.

For the most part this was fairly straightforward, and the patch size is
relatively small.  The implementation of some existing CompressedOops
"primitives" required adjustment. An explicit conversion to narrowOop was
added, with casts change to use it.  There were a few places that were type
punning and needed explicit conversions,, mostly in platform-specific assembly
support.

There are a couple of lingering problems.

Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
this probably ought to be done differently.

There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
whether these can be safely converted to CompressedOops::narrow_oop_cast.

There might still be some casts from narrowOop to an integral type.  Those are
hard to find in our cast-happy code base.

Testing:
tier1-6 for Oracle supported platforms.
Build fastdebug linux-ppc64le and linux-s390x.

-------------

Commit messages:
 - 8247912: Make narrowOop a scoped enum

Changes: https://git.openjdk.java.net/jdk/pull/273/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247912
  Stats: 83 lines in 22 files changed: 32 ins; 5 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273

PR: https://git.openjdk.java.net/jdk/pull/273

From shade at openjdk.java.net  Mon Sep 21 05:55:28 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 21 Sep 2020 05:55:28 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v4]
In-Reply-To: <pPOy9agQdCtjXRFexMi3ma_eLRergiGlweeKCDaXGUY=.8ef5a687-2966-4472-a92d-067b33c20e5a@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <pPOy9agQdCtjXRFexMi3ma_eLRergiGlweeKCDaXGUY=.8ef5a687-2966-4472-a92d-067b33c20e5a@github.com>
Message-ID: <z19FnwEwaD1cON6yVW402tfb8EeWiQHZetQvQlAyo9A=.fbfc41e9-ec15-4b2f-8c78-ad4412740899@github.com>

On Mon, 21 Sep 2020 02:36:18 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> - enable parallel heap inspecton for ShenandoahHeap
>>   - preliminary evaluation:
>>     Time of jmap histo on (8GB heap with 4GB objects)
>>     * before: 5.186s
>>     * after : 1.698s
>
> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
> will show differences compared to the previous content of the PR.

Thanks, this looks very good. I have only a few minor stylistic leftovers. Other than that, it seems ready to integrate.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1496:

> 1494: };
> 1495:
> 1496: ParallelObjectIterator* ShenandoahHeap::parallel_object_iterator(uint num_workers) {

`num_workers` -> `workers`

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 560:

> 558:   void object_iterate(ObjectClosure* cl);
> 559:   // Parallel heap iteration support
> 560:   virtual ParallelObjectIterator* parallel_object_iterator(uint thread_num);

`thread_num` -> `workers`

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 531:

> 529:   void finish_concurrent_unloading();
> 530:   // Heap iteration support
> 531:   void scan_roots_for_iteration(Stack<oop, mtGC>* oop_stack, ObjectIterateScanRootClosure* oops);

Let's `typedef Stack<oop, mtGC> ShenandoahScanRootStack` and use it everywhere?

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/67

From shade at redhat.com  Mon Sep 21 06:15:23 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 21 Sep 2020 08:15:23 +0200
Subject: [11u] RFR (S) 8252660: Shenandoah: support manageable
 SoftMaxHeapSize option
In-Reply-To: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com>
References: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com>
Message-ID: <bcff1628-4c49-17b8-fcf9-abab239ed6cd@redhat.com>

Friendly reminder.

On 9/7/20 1:29 PM, Aleksey Shipilev wrote:
> Original RFE:
>     https://bugs.openjdk.java.net/browse/JDK-8252660
>     https://hg.openjdk.java.net/jdk/jdk/rev/6ab9279c0e99
> 
> The patch does not apply cleanly to 11u, because there are conflicts in APIs.
> 
> I had to resolve these:
>     *) There is no Atomic::store(&size_t, size_t), replaced with OrderAccess::release_store_fence, as
> in other places in 11u.
>     *) There is no global SoftMaxHeapSize, replaced it with ShenandoahSoftMaxHeapSize and added
> relevant verifications to make new Shenandoah tests pass.
> 
> 11u webrev:
>     https://cr.openjdk.java.net/~shade/8252660/webrev.11u.01/
> 
> Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah


-- 
Thanks,
-Aleksey


From mbeckwit at openjdk.java.net  Mon Sep 21 07:14:52 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 21 Sep 2020 07:14:52 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <9ex1cWVOzjYIl9WtLrMt_hGrAQDKPNu5afUME7dfM9o=.e5cee81f-4bd6-4896-bd90-f713585bff37@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has refreshed the contents of this pull request, and previous commits have been removed. The
incremental views will show differences compared to the previous content of the PR. The pull request contains six new
commits since the last revision:

 - 8248787: G1: Workaround MSVC bug
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248670: Windows: Exception handling support on AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248660: AArch64: Make _clear_cache and _nop portable
   Summary: __builtin___clear_cache, etc.
   Contributed-by: mbeckwit, luhenry, burban
 - 8248659: AArch64: Extend CPU Feature detection
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248656: Add Windows AArch64 platform support code
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248498: Add build system support for Windows AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/26e4af3a..5f9b0d35

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Mon Sep 21 07:14:52 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 21 Sep 2020 07:14:52 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]
In-Reply-To: <RN3cacKvAfMGjCpxdH2mdvPJH9XwKmAIUCDtNzgFpMw=.7060b196-467f-4ae2-b527-7f5bf938ab8f@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <axvLamk-3k-CVBfcyN0Nc59o1619WwmDwm4wweMX2M4=.1fa21044-7b40-4107-abb3-ccd40b0fd923@github.com>
 <RN3cacKvAfMGjCpxdH2mdvPJH9XwKmAIUCDtNzgFpMw=.7060b196-467f-4ae2-b527-7f5bf938ab8f@github.com>
Message-ID: <k0i1glu5zv2pPnRHqDCGkTCvMW5tA1rWUhW0tMPLmfs=.b3ea3c93-7ecd-4aee-9218-0df755df6fef@github.com>

On Fri, 18 Sep 2020 20:34:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I assume you need the rest of the PATH on Windows.

Doesn't look like it actually. I've reverted it, thanks for catching it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From lzang at openjdk.java.net  Mon Sep 21 07:20:58 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 21 Sep 2020 07:20:58 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v5]
In-Reply-To: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
Message-ID: <LIfwn-tOTYdeeV7mFqznWmddv3M-G-fg1NjCkkCbtzo=.d90f4fb7-d5cb-4027-b0d3-2686d76b05c2@github.com>

> - enable parallel heap inspecton for ShenandoahHeap
>   - preliminary evaluation:
>     Time of jmap histo on (8GB heap with 4GB objects)
>     * before: 5.186s
>     * after : 1.698s

Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
will show differences compared to the previous content of the PR. The pull request contains one new commit since the
last revision:

  8252104: parallel heap inspection for ShenandoahHeap
  
    - enable parallel heap inspecton for ShenandoahHeap
    - preliminary evaluation:
      Time of jmap histo on (8GB heap with 4GB objects)
      * before: 5.186s
      * after : 1.698s

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/67/files
  - new: https://git.openjdk.java.net/jdk/pull/67/files/1fddea7c..a1b6a76c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=03-04

  Stats: 10 lines in 2 files changed: 1 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/67/head:pull/67

PR: https://git.openjdk.java.net/jdk/pull/67

From lzang at openjdk.java.net  Mon Sep 21 07:20:59 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 21 Sep 2020 07:20:59 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v4]
In-Reply-To: <z19FnwEwaD1cON6yVW402tfb8EeWiQHZetQvQlAyo9A=.fbfc41e9-ec15-4b2f-8c78-ad4412740899@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <pPOy9agQdCtjXRFexMi3ma_eLRergiGlweeKCDaXGUY=.8ef5a687-2966-4472-a92d-067b33c20e5a@github.com>
 <z19FnwEwaD1cON6yVW402tfb8EeWiQHZetQvQlAyo9A=.fbfc41e9-ec15-4b2f-8c78-ad4412740899@github.com>
Message-ID: <N-Us2ckWDRtQksKUpKw9XXs2N8xS2YI7Ba5BBS4IpUA=.605f75d1-e74f-46a5-9308-e8400c001cf4@github.com>

On Mon, 21 Sep 2020 05:52:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR. The pull request contains one new commit since the
>> last revision:
>>   8252104: parallel heap inspection for ShenandoahHeap
>>   
>>     - enable parallel heap inspecton for ShenandoahHeap
>>     - preliminary evaluation:
>>       Time of jmap histo on (8GB heap with 4GB objects)
>>       * before: 5.186s
>>       * after : 1.698s
>
> Thanks, this looks very good. I have only a few minor stylistic leftovers. Other than that, it seems ready to integrate.

Dear @shipilev,
   I just updated the patch.  may I ask your help to review and merge it if there is no problem? Thanks!
-Lin

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 531:
> 
>> 529:   void finish_concurrent_unloading();
>> 530:   // Heap iteration support
>> 531:   void scan_roots_for_iteration(Stack<oop, mtGC>* oop_stack, ObjectIterateScanRootClosure* oops);
> 
> Let's `typedef Stack<oop, mtGC> ShenandoahScanRootStack` and use it everywhere?

As this Stack is also used for iterating all objects (not only roots), so I took the liberty to rename it to
ShenandoahScanObjectStack :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From shade at openjdk.java.net  Mon Sep 21 07:26:48 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 21 Sep 2020 07:26:48 GMT
Subject: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v4]
In-Reply-To: <N-Us2ckWDRtQksKUpKw9XXs2N8xS2YI7Ba5BBS4IpUA=.605f75d1-e74f-46a5-9308-e8400c001cf4@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
 <pPOy9agQdCtjXRFexMi3ma_eLRergiGlweeKCDaXGUY=.8ef5a687-2966-4472-a92d-067b33c20e5a@github.com>
 <z19FnwEwaD1cON6yVW402tfb8EeWiQHZetQvQlAyo9A=.fbfc41e9-ec15-4b2f-8c78-ad4412740899@github.com>
 <N-Us2ckWDRtQksKUpKw9XXs2N8xS2YI7Ba5BBS4IpUA=.605f75d1-e74f-46a5-9308-e8400c001cf4@github.com>
Message-ID: <ctzlqVvCwSqkXk7WtpXLmee2jTFpbxMRZWefzM8-EVM=.0680c2ca-8c3b-4455-af56-82392d3c7fd5@github.com>

On Mon, 21 Sep 2020 07:14:43 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Thanks, this looks very good. I have only a few minor stylistic leftovers. Other than that, it seems ready to integrate.
>
> Dear @shipilev,
>    I just updated the patch.  may I ask your help to review and merge it if there is no problem? Thanks!
> -Lin

Thank you, this looks good. I'll run a few local test and then sponsor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From lzang at openjdk.java.net  Mon Sep 21 07:54:17 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 21 Sep 2020 07:54:17 GMT
Subject: Integrated: 8252104: parallel heap inspection for ShenandoahHeap
In-Reply-To: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
References: <KooB02kCy-YN_yt4MYsd5JqPqQdoEfrMvuZQxyeaGz0=.a7cf311c-3f8d-46e1-b14c-3add94eac0e4@github.com>
Message-ID: <HSmJ_YK11j86WonVSME3AtupyLyn9YhQpUo_mK5Nqww=.4a106fbb-8a5d-4f61-9391-ea339ac0018c@github.com>

On Tue, 8 Sep 2020 03:15:10 GMT, Lin Zang <lzang at openjdk.org> wrote:

> - enable parallel heap inspecton for ShenandoahHeap
>   - preliminary evaluation:
>     Time of jmap histo on (8GB heap with 4GB objects)
>     * before: 5.186s
>     * after : 1.698s

This pull request has now been integrated.

Changeset: 34ec1bed
Author:    Lin Zang <lzang at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/34ec1bed
Stats:     202 lines in 2 files changed: 16 ins; 180 del; 6 mod

8252104: parallel heap inspection for ShenandoahHeap

Reviewed-by: shade, zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/67

From burban at openjdk.java.net  Mon Sep 21 08:18:21 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 21 Sep 2020 08:18:21 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]
In-Reply-To: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>
 <BtXRWhdTVMJd1UyIAZTtUbCxnAfM20wCvbigZvdlbDk=.87224bc2-3fe9-4790-9602-f7e8c264f31b@github.com>
 <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com>
Message-ID: <eDF4lO_5Em7jD5uxcMo1Rhqnszco-Yc3Ugw676OeIos=.de33e8d4-208c-454c-836a-60f9af4e0ef1@github.com>

On Fri, 18 Sep 2020 18:38:34 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Our linux-aarch64 build fails with this:
>> cc: error: unrecognized command line option '-std=c++14'
>> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch
>> 
>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing,
>> and if so, how are you addressing it?
>
> Hey @erikj79, thank you so much for giving it a try!
> 
>> Our linux-aarch64 build fails with this:
>> cc: error: unrecognized command line option '-std=c++14'
>> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch
> 
> Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on
> such a system: $ cat /etc/issue
> Ubuntu 19.10 \n \l
> $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg
> $ make clean CONF=linux-aarch64-server-release
> $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release
> $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64
>     java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk
>     os.arch = aarch64
>     sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib
> --------------------------------------------------------
>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing,
>> and if so, how are you addressing it?
> 
> Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on
> Windows targets (as it hasn't been a thing so far). We use a workaround internally
> https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on
> build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> On 18/09/2020 11:14, Monica Beckwith wrote:
> 
> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
> 
> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this.


Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the
retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part
would look indeed nicer with that:  https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):

--- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
+++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
@@ -13,6 +13,8 @@ class Register(Operand):

     def generate(self):
         self.number = random.randint(0, 30)
+        if self.number == 18:
+            self.number = 17
         return self

     def astr(self, prefix):
@@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register):

     def generate(self):
         self.number = random.randint(0, 31)
+        if self.number == 18:
+            self.number = 16
         return self

     def astr(self, prefix = ""):
@@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register):
 class GeneralRegisterOrSp(Register):
     def generate(self):
         self.number = random.randint(0, 31)
+        if self.number == 18:
+            self.number = 15
         return self

     def astr(self, prefix = ""):
@@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn",   "__ ccmn(zr, zr, 3u, Assembler::LE);",
                         ["st1w",   "__ sve_st1w(z0, __ S, p1, Address(r0, 7));",         "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"],
                         ["st1b",   "__ sve_st1b(z0, __ B, p2, Address(sp, r1));",        "st1b\t{z0.b}, p2, [sp, x1]"],
                         ["st1h",   "__ sve_st1h(z0, __ H, p3, Address(sp, r8));",        "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"],
-                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r18));",       "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"],
+                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r17));",       "st1d\t{z0.d}, p4, [x0, x17,
LSL #3]"],
                         ["ldr",    "__ sve_ldr(z0, Address(sp));",                       "ldr\tz0, [sp]"],
                         ["ldr",    "__ sve_ldr(z31, Address(sp, -256));",                "ldr\tz31, [sp, #-256, MUL VL]"],
                         ["str",    "__ sve_str(z8, Address(r8, 255));",                  "str\tz8, [x8, #255, MUL VL]"],

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From rkennke at openjdk.java.net  Mon Sep 21 08:34:44 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 21 Sep 2020 08:34:44 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <BMA3uuq6gZcoiTvhHJwv_m6lKfGoyrM6ugirz_GZ4V8=.4253d6a8-47c8-4b83-855c-77b4d9a81180@github.com>

On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for
something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The
next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid
that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From ngasson at openjdk.java.net  Mon Sep 21 09:11:22 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 21 Sep 2020 09:11:22 GMT
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent
Message-ID: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>

C1 atomic operations are supposed to be sequentially consistent by
default but the variant in the Shenandoah C1 barrier set assembler only
provides a half-barrier when the CAS succeeds. Added a trailing full
barrier and load-acquire to exactly match the non-Shenandoah C1 CAS
implementation. This prevents any memory accesses following the CAS
operation being observed before it.

Also adjusted the documentation for ShenandoahBarrierSetAssembler
::cmpxchg_oop as it currently claims to be sequentially consistent by
default but it's not clear what the "default" values of acquire and
release should be, and the comment for acquire/release implies to me
that setting them to true would relax the ordering guarantees but
actually it's the opposite. I tried to simplify this and make it less
ambiguous.

One other thing I noticed when reading this: the comment

   // Step 4. CAS has failed because the value most recently fetched
   // from addr (which is now held in tmp1) ...

is wrong on non-LSE systems because tmp1 is rscratch1 and that is
clobbered by the call to __ cmpxchg() at the end of step3. Although it
doesn't matter because the value in tmp1 is not used after that point.
Adjusted the comment to clarify this.

Tested hotspot_all_no_apps, jdk_core plus jcstress with -jvmArgs
'-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'.

-------------

Commit messages:
 - 8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent

Changes: https://git.openjdk.java.net/jdk/pull/280/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=280&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252857
  Stats: 39 lines in 2 files changed: 5 ins; 22 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/280.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/280/head:pull/280

PR: https://git.openjdk.java.net/jdk/pull/280

From kim.barrett at oracle.com  Mon Sep 21 09:18:03 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 21 Sep 2020 05:18:03 -0400
Subject: RFR: 8247912: Make narrowOop a scoped enum
In-Reply-To: <BMA3uuq6gZcoiTvhHJwv_m6lKfGoyrM6ugirz_GZ4V8=.4253d6a8-47c8-4b83-855c-77b4d9a81180@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <BMA3uuq6gZcoiTvhHJwv_m6lKfGoyrM6ugirz_GZ4V8=.4253d6a8-47c8-4b83-855c-77b4d9a81180@github.com>
Message-ID: <0AD7BDBF-AC28-46C9-AD07-B4CD23C5916A@oracle.com>

> On Sep 21, 2020, at 4:34 AM, Roman Kennke <rkennke at openjdk.java.net> wrote:
> 
> On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> 
>> [?]
> 
> I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for
> something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The
> next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid
> that.

This is a normal and well-established use of scoped enums as type-safe
integral-like values. Examples from the C++17 Standard include std::byte and
std::align_val_t. I've also seen type-safe integer arithmetic done this way,
eliminating that nasty implicit promotion and conversion stuff that can get
one into so much trouble. I'm sure I can produce more examples if needed.


From aph at redhat.com  Mon Sep 21 09:30:18 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 21 Sep 2020 10:30:18 +0100
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]
In-Reply-To: <eDF4lO_5Em7jD5uxcMo1Rhqnszco-Yc3Ugw676OeIos=.de33e8d4-208c-454c-836a-60f9af4e0ef1@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>
 <BtXRWhdTVMJd1UyIAZTtUbCxnAfM20wCvbigZvdlbDk=.87224bc2-3fe9-4790-9602-f7e8c264f31b@github.com>
 <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com>
 <eDF4lO_5Em7jD5uxcMo1Rhqnszco-Yc3Ugw676OeIos=.de33e8d4-208c-454c-836a-60f9af4e0ef1@github.com>
Message-ID: <dfff459c-2713-e3fa-5a4d-9593a2021e9b@redhat.com>

On 21/09/2020 09:18, Bernhard Urban-Forster wrote:
> Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the
> retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part
> would look indeed nicer with that:  https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
> 
> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> @@ -13,6 +13,8 @@ class Register(Operand):
> 
>      def generate(self):
>          self.number = random.randint(0, 30)
> +        if self.number == 18:
> +            self.number = 17

Yes, better. Thanks.

-- 
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 openjdk.java.net  Mon Sep 21 09:52:18 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 21 Sep 2020 09:52:18 GMT
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent
In-Reply-To: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
Message-ID: <HTaGo6SkguPaB-S4Cam_tjKALpmzsAgbpqi28LxjUP0=.ff8361a9-425d-4a17-acda-fd09ede33056@github.com>

On Mon, 21 Sep 2020 09:04:15 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> C1 atomic operations are supposed to be sequentially consistent by
> default but the variant in the Shenandoah C1 barrier set assembler only
> provides a half-barrier when the CAS succeeds. Added a trailing full
> barrier and load-acquire to exactly match the non-Shenandoah C1 CAS
> implementation. This prevents any memory accesses following the CAS
> operation being observed before it.
> 
> Also adjusted the documentation for ShenandoahBarrierSetAssembler
> ::cmpxchg_oop as it currently claims to be sequentially consistent by
> default but it's not clear what the "default" values of acquire and
> release should be, and the comment for acquire/release implies to me
> that setting them to true would relax the ordering guarantees but
> actually it's the opposite. I tried to simplify this and make it less
> ambiguous.
> 
> One other thing I noticed when reading this: the comment
> 
>    // Step 4. CAS has failed because the value most recently fetched
>    // from addr (which is now held in tmp1) ...
> 
> is wrong on non-LSE systems because tmp1 is rscratch1 and that is
> clobbered by the call to __ cmpxchg() at the end of step3. Although it
> doesn't matter because the value in tmp1 is not used after that point.
> Adjusted the comment to clarify this.
> 
> Tested hotspot_all_no_apps, jdk_core plus jcstress with -jvmArgs
> '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'.

Looks good to me. @shipilev should look at it, too.

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/280

From rkennke at openjdk.java.net  Mon Sep 21 10:01:29 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 21 Sep 2020 10:01:29 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum
In-Reply-To: <BMA3uuq6gZcoiTvhHJwv_m6lKfGoyrM6ugirz_GZ4V8=.4253d6a8-47c8-4b83-855c-77b4d9a81180@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <BMA3uuq6gZcoiTvhHJwv_m6lKfGoyrM6ugirz_GZ4V8=.4253d6a8-47c8-4b83-855c-77b4d9a81180@github.com>
Message-ID: <rNJTG7Kzmlv4lIvbyeKPJuE_KAzj6yaNbJiAON-tr18=.982b1b47-7aba-44da-aa5e-8968caf811bf@github.com>

On Mon, 21 Sep 2020 08:32:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Please review this change to the type narrowOop from a typedef for juint to a
>> scoped enum with uint32_t as the representation type.  This provides stronger
>> type checking when using this type.
>> 
>> For the most part this was fairly straightforward, and the patch size is
>> relatively small.  The implementation of some existing CompressedOops
>> "primitives" required adjustment. An explicit conversion to narrowOop was
>> added, with casts change to use it.  There were a few places that were type
>> punning and needed explicit conversions,, mostly in platform-specific assembly
>> support.
>> 
>> There are a couple of lingering problems.
>> 
>> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
>> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
>> this probably ought to be done differently.
>> 
>> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
>> whether these can be safely converted to CompressedOops::narrow_oop_cast.
>> 
>> There might still be some casts from narrowOop to an integral type.  Those are
>> hard to find in our cast-happy code base.
>> 
>> Testing:
>> tier1-6 for Oracle supported platforms.
>> Build fastdebug linux-ppc64le and linux-s390x.
>
> I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for
> something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The
> next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid
> that.

> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on
> [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_
> > On Sep 21, 2020, at 4:34 AM, Roman Kennke <rkennke at openjdk.java.net> wrote:
> > On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> > > [?]
> > 
> > 
> > I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for
> > something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The
> > next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid
> > that.
> 
> This is a normal and well-established use of scoped enums as type-safe
> integral-like values. Examples from the C++17 Standard include std::byte and
> std::align_val_t. I've also seen type-safe integer arithmetic done this way,
> eliminating that nasty implicit promotion and conversion stuff that can get
> one into so much trouble. I'm sure I can produce more examples if needed.

Hmm ok. Thanks for clarification.
Roman

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From aph at redhat.com  Mon Sep 21 10:23:47 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 21 Sep 2020 11:23:47 +0100
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent
In-Reply-To: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
Message-ID: <4d250323-bffa-3d73-6ca7-de9190cf559e@redhat.com>

On 21/09/2020 10:11, Nick Gasson wrote:
> C1 atomic operations are supposed to be sequentially consistent by
> default but the variant in the Shenandoah C1 barrier set assembler only
> provides a half-barrier when the CAS succeeds. Added a trailing full
> barrier and load-acquire to exactly match the non-Shenandoah C1 CAS
> implementation. This prevents any memory accesses following the CAS
> operation being observed before it.

We only need the trailing membar if is_c1_or_interpreter_only(). Otherwise
all volatile loads in C1 are preceded by a leading membar() so we don't
need a trailing one as well.

>> 462 // By default, this operation has relaxed memory ordering

No, it has whatever memory ordering you tell it. Plus, if you pass
both acquire and release, sequential consistency.

-- 
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 zgu at redhat.com  Mon Sep 21 14:21:19 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 21 Sep 2020 10:21:19 -0400
Subject: [11u] RFR (S) 8252660: Shenandoah: support manageable
 SoftMaxHeapSize option
In-Reply-To: <bcff1628-4c49-17b8-fcf9-abab239ed6cd@redhat.com>
References: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com>
 <bcff1628-4c49-17b8-fcf9-abab239ed6cd@redhat.com>
Message-ID: <dac7c6df-df8f-4403-34d0-2a57156e30cb@redhat.com>

Good to me.

Thanks,

-Zhengyu

On 9/21/20 2:15 AM, Aleksey Shipilev wrote:
> Friendly reminder.
> 
> On 9/7/20 1:29 PM, Aleksey Shipilev wrote:
>> Original RFE:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8252660
>> ??? https://hg.openjdk.java.net/jdk/jdk/rev/6ab9279c0e99
>>
>> The patch does not apply cleanly to 11u, because there are conflicts 
>> in APIs.
>>
>> I had to resolve these:
>> ??? *) There is no Atomic::store(&size_t, size_t), replaced with 
>> OrderAccess::release_store_fence, as
>> in other places in 11u.
>> ??? *) There is no global SoftMaxHeapSize, replaced it with 
>> ShenandoahSoftMaxHeapSize and added
>> relevant verifications to make new Shenandoah tests pass.
>>
>> 11u webrev:
>> ??? https://cr.openjdk.java.net/~shade/8252660/webrev.11u.01/
>>
>> Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah
> 
> 


From mbeckwit at openjdk.java.net  Mon Sep 21 14:55:26 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 21 Sep 2020 14:55:26 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <EahiXUGuCz1FrZdIh7Egrqpjbng7SXt7-xpcZZwlTro=.af12356e-91fd-44c9-bdae-6f11f545b5a2@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has refreshed the contents of this pull request, and previous commits have been removed. The
incremental views will show differences compared to the previous content of the PR. The pull request contains 11 new
commits since the last revision:

 - 8248787: G1: Workaround MSVC bug
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248670: Windows: Exception handling support on AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248660: AArch64: Make _clear_cache and _nop portable
   Summary: __builtin___clear_cache, etc.
   Contributed-by: mbeckwit, luhenry, burban
 - 8248659: AArch64: Extend CPU Feature detection
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248656: Add Windows AArch64 platform support code
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248498: Add build system support for Windows AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248663: AArch64: Avoid existing macros/keywords of MSVC
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248676: AArch64: Add workaround for LITable constructor
   Reviewed-by: aph
   Contributed-by: mbeckwit, luhenry, burban
 - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests)
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/5f9b0d35...3881b12d

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/5f9b0d35..3881b12d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=01-02

  Stats: 1366 lines in 2 files changed: 6 ins; 4 del; 1356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Mon Sep 21 14:55:27 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 21 Sep 2020 14:55:27 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]
In-Reply-To: <eDF4lO_5Em7jD5uxcMo1Rhqnszco-Yc3Ugw676OeIos=.de33e8d4-208c-454c-836a-60f9af4e0ef1@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>
 <BtXRWhdTVMJd1UyIAZTtUbCxnAfM20wCvbigZvdlbDk=.87224bc2-3fe9-4790-9602-f7e8c264f31b@github.com>
 <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com>
 <eDF4lO_5Em7jD5uxcMo1Rhqnszco-Yc3Ugw676OeIos=.de33e8d4-208c-454c-836a-60f9af4e0ef1@github.com>
Message-ID: <qURWEYTydROTURbaHd9Lw5G9BTvCkLlpD7ybgTxkycg=.77cee65f-1a42-4d00-a7f7-3a911fbfa6be@github.com>

On Mon, 21 Sep 2020 08:15:20 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Hey @erikj79, thank you so much for giving it a try!
>> 
>>> Our linux-aarch64 build fails with this:
>>> cc: error: unrecognized command line option '-std=c++14'
>>> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch
>> 
>> Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on
>> such a system: $ cat /etc/issue
>> Ubuntu 19.10 \n \l
>> $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg
>> $ make clean CONF=linux-aarch64-server-release
>> $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release
>> $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64
>>     java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk
>>     os.arch = aarch64
>>     sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib
>> --------------------------------------------------------
>>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing,
>>> and if so, how are you addressing it?
>> 
>> Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on
>> Windows targets (as it hasn't been a thing so far). We use a workaround internally
>> https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on
>> build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
>> 
>> On 18/09/2020 11:14, Monica Beckwith wrote:
>> 
>> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>> 
>> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this.
> 
> 
> Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the
> retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part
> would look indeed nicer with that:  https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
> @@ -13,6 +13,8 @@ class Register(Operand):
> 
>      def generate(self):
>          self.number = random.randint(0, 30)
> +        if self.number == 18:
> +            self.number = 17
>          return self
> 
>      def astr(self, prefix):
> @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register):
> 
>      def generate(self):
>          self.number = random.randint(0, 31)
> +        if self.number == 18:
> +            self.number = 16
>          return self
> 
>      def astr(self, prefix = ""):
> @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register):
>  class GeneralRegisterOrSp(Register):
>      def generate(self):
>          self.number = random.randint(0, 31)
> +        if self.number == 18:
> +            self.number = 15
>          return self
> 
>      def astr(self, prefix = ""):
> @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn",   "__ ccmn(zr, zr, 3u, Assembler::LE);",
>                          ["st1w",   "__ sve_st1w(z0, __ S, p1, Address(r0, 7));",         "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"],
>                          ["st1b",   "__ sve_st1b(z0, __ B, p2, Address(sp, r1));",        "st1b\t{z0.b}, p2, [sp, x1]"],
>                          ["st1h",   "__ sve_st1h(z0, __ H, p3, Address(sp, r8));",        "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"],
> -                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r18));",       "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"],
> +                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r17));",       "st1d\t{z0.d}, p4, [x0, x17,
> LSL #3]"],
>                          ["ldr",    "__ sve_ldr(z0, Address(sp));",                       "ldr\tz0, [sp]"],
>                          ["ldr",    "__ sve_ldr(z31, Address(sp, -256));",                "ldr\tz31, [sp, #-256, MUL VL]"],
>                          ["str",    "__ sve_str(z8, Address(r8, 255));",                  "str\tz8, [x8, #255, MUL VL]"],

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> On 21/09/2020 09:18, Bernhard Urban-Forster wrote:
> 
> > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the
> > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part
> > would look indeed nicer with that:  https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
> > [...]
> 
> Yes, better. Thanks.

Great, I've updated the PR. Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From zgu at openjdk.java.net  Mon Sep 21 18:18:58 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 21 Sep 2020 18:18:58 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner
Message-ID: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>

After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
ShenandoahRootScanner::roots_do() are practical the same, let's trim one.

Test:
  hotspot_gc_shenandoah

-------------

Commit messages:
 - Trim ShenandoahRootScanner

Changes: https://git.openjdk.java.net/jdk/pull/286/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=286&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253434
  Stats: 48 lines in 3 files changed: 2 ins; 43 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/286/head:pull/286

PR: https://git.openjdk.java.net/jdk/pull/286

From rkennke at openjdk.java.net  Mon Sep 21 18:31:00 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 21 Sep 2020 18:31:00 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner
In-Reply-To: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
Message-ID: <Ospfef61G13HnkAXnuhYxh0M9-6tfY1Uh3SwUTNcYX8=.db95fa04-a120-401f-8b32-a6c7fc5db56b@github.com>

On Mon, 21 Sep 2020 18:11:10 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
> Test:
>   hotspot_gc_shenandoah

It looks to me you can also trim out the CLD closures altogether.

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 192:

> 190:
> 191: void ShenandoahRootScanner::roots_do(uint worker_id, OopClosure* oops) {
> 192:   CLDToOopClosure clds_cl(oops, ClassLoaderData::_claim_none);

Are you sure that we don't have to claim CLDs? How would the threads avoid doubly-marking CLDs?

-------------

PR: https://git.openjdk.java.net/jdk/pull/286

From rkennke at openjdk.java.net  Mon Sep 21 18:31:01 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 21 Sep 2020 18:31:01 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner
In-Reply-To: <Ospfef61G13HnkAXnuhYxh0M9-6tfY1Uh3SwUTNcYX8=.db95fa04-a120-401f-8b32-a6c7fc5db56b@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
 <Ospfef61G13HnkAXnuhYxh0M9-6tfY1Uh3SwUTNcYX8=.db95fa04-a120-401f-8b32-a6c7fc5db56b@github.com>
Message-ID: <xRLooCBGgQZLIk8FHSGKUyPYbreKcI8R6jSCtbQOKLU=.a441a929-7750-4518-b1c0-7049c3297a6a@github.com>

On Mon, 21 Sep 2020 18:25:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
>> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
>> Test:
>>   hotspot_gc_shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 192:
> 
>> 190:
>> 191: void ShenandoahRootScanner::roots_do(uint worker_id, OopClosure* oops) {
>> 192:   CLDToOopClosure clds_cl(oops, ClassLoaderData::_claim_none);
> 
> Are you sure that we don't have to claim CLDs? How would the threads avoid doubly-marking CLDs?

Actually it looks like the CLD closure is not used at all, or is it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/286

From zgu at openjdk.java.net  Mon Sep 21 20:08:28 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 21 Sep 2020 20:08:28 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner [v2]
In-Reply-To: <xRLooCBGgQZLIk8FHSGKUyPYbreKcI8R6jSCtbQOKLU=.a441a929-7750-4518-b1c0-7049c3297a6a@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
 <Ospfef61G13HnkAXnuhYxh0M9-6tfY1Uh3SwUTNcYX8=.db95fa04-a120-401f-8b32-a6c7fc5db56b@github.com>
 <xRLooCBGgQZLIk8FHSGKUyPYbreKcI8R6jSCtbQOKLU=.a441a929-7750-4518-b1c0-7049c3297a6a@github.com>
Message-ID: <05l8R9_NCFWqb3t5oLUREPCUKyqxvCmUuLmxmnaXpNM=.35adf98d-ce4d-4454-b8e6-a43687766d97@github.com>

On Mon, 21 Sep 2020 18:27:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 192:
>> 
>>> 190:
>>> 191: void ShenandoahRootScanner::roots_do(uint worker_id, OopClosure* oops) {
>>> 192:   CLDToOopClosure clds_cl(oops, ClassLoaderData::_claim_none);
>> 
>> Are you sure that we don't have to claim CLDs? How would the threads avoid doubly-marking CLDs?
>
> Actually it looks like the CLD closure is not used at all, or is it?

Right, we don't need to mark on-stack CLDs, concurrent mark CLDs should be sufficient.

Reran tests, still good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/286

From zgu at openjdk.java.net  Mon Sep 21 20:08:28 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 21 Sep 2020 20:08:28 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner [v2]
In-Reply-To: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
Message-ID: <ypjKa2lXMpxUImcJjw0MxH8n1bUqOXwYCzB3lOEVt9o=.6f0bfd0f-a0f7-4677-b34c-71b64664f16d@github.com>

> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
> Test:
>   hotspot_gc_shenandoah

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  No need to mark on-stack CLD

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/286/files
  - new: https://git.openjdk.java.net/jdk/pull/286/files/a6d797c3..66492e4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=286&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=286&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/286/head:pull/286

PR: https://git.openjdk.java.net/jdk/pull/286

From iklam at openjdk.java.net  Mon Sep 21 21:32:19 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 21 Sep 2020 21:32:19 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <QT2zMafa6XgnfdR0r6oVSTijc98N0i1EJoiy628I67w=.3d2a3e77-7a0b-42b8-85e2-f36df1915d9f@github.com>

On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

This looks good overall to me.

src/hotspot/share/oops/compressedOops.hpp line 142:

> 140:     // Shift by 32 is UB if size in bits of i is 32, e.g. on 32bit platform.
> 141:     assert(((i >> 16) >> 16) == 0, "narrowOop overflow");
> 142:     return static_cast<narrowOop>(static_cast<NarrowType>(i));

Should we have an assert that further restricts the range according to max heap size?

Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be
flagged.

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/273

From iklam at openjdk.java.net  Mon Sep 21 21:44:21 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 21 Sep 2020 21:44:21 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <wdW2sHqWb01hda4tJYu4J3rXaAxx05dLGRudJYVqWQ8=.d5a0a77b-ab36-4cbc-9f0a-fa535b3d0020@github.com>

On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179:

> 177:     // Move narrow OOP
> 178:     narrowOop noop = CompressedOops::encode((oop)o);
> 179:     CompressedOops::NarrowType n = CompressedOops::narrow_oop_value(noop);

I think a public NarrowType is confusing (vs narrowOop). Since NarrowType is rarely used, and it's unlikely to be
changed from uint32_t, maybe we should make NarrowType private, and change the above to uint32_t n =
CompressedOops::encode_as_uint32_t((oop)o); Code that does arithmetic operations on the integer value probably wants to
know the exact type anyway. I.e., not knowing whether NarrowType is signed or not makes me worry about the correctness
of `n >> 16` below.

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From dcubed at openjdk.java.net  Mon Sep 21 22:15:34 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 21 Sep 2020 22:15:34 GMT
Subject: Integrated: 8247281: migrate ObjectMonitor::_object to OopStorage
In-Reply-To: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
References: <g9gjuGNAm1lHF_aEeALNObFCynBPxWB0_yd69T4pT84=.1f8aa979-8bee-495f-ae74-857323ad9d43@github.com>
Message-ID: <K1GOognQMbbvBK5VhtxzgCa-QokImmNZ6VHiF6TsrXg=.1d115edb-0f8c-446f-8289-0ac59e4ecd7a@github.com>

On Fri, 11 Sep 2020 18:45:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This RFE is to migrate the following field to OopStorage:
> 
> class ObjectMonitor {
> <snip>
>   void* volatile _object; // backward object pointer - strong root
> 
> Unlike the previous patches in this series, there are a lot of collateral
> changes so this is not a trivial review. Sorry for the tedious parts of
> the review. Since Erik and I are both contributors to this patch, we
> would like at least 1 GC team reviewer and 1 Runtime team reviewer.
> 
> This changeset was tested with Mach5 Tier[1-3],4,5,6,7,8 testing
> along with JDK-8252980 and JDK-8252981. I also ran it through my
> inflation stress kit for 48 hours on my Linux-X64 machine.

This pull request has now been integrated.

Changeset: d8921ed5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d8921ed5
Stats:     457 lines in 37 files changed: 246 ins; 113 del; 98 mod

8247281: migrate ObjectMonitor::_object to OopStorage

Co-authored-by: Erik ?sterlund <erik.osterlund at oracle.com>
Co-authored-by: Daniel Daugherty <daniel.daugherty at oracle.com>
Reviewed-by: eosterlund, coleenp, dholmes, stefank, kbarrett, rkennke, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/135

From akozlov at openjdk.java.net  Tue Sep 22 07:16:38 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 22 Sep 2020 07:16:38 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
Message-ID: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>

Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html

On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL,
PROT_NONE), the function was made aware of exec permissions.

For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference
compared with old code.

For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and
immediately reflects this in diagnostic tools like ps.  For executable regions it would require MAP_FIXED|MAP_JIT, so
instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently
this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not
shrink (if I haven't missed anything, by the implementation and in principle).

Tested:
* local tier1
* jdk-submit
* codesign[2] with hardened runtime and allow-jit but without
allow-unsigned-executable-memory entitlements[3] produce a working bundle.

(adding GC group as suggested by @dholmes-ora)


[1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227
[2]
 
  codesign \
    --sign - \
    --options runtime \
    --entitlements ents.plist \
    --timestamp \
    $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib
[3]
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
      <key>com.apple.security.cs.allow-jit</key>
      <true/>
      <key>com.apple.security.cs.disable-library-validation</key>
      <true/>
      <key>com.apple.security.cs.allow-dyld-environment-variables</key>
      <true/>
    </dict>
  </plist>

-------------

Commit messages:
 - Use MAP_JIT for CodeCache pages

Changes: https://git.openjdk.java.net/jdk/pull/294/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234930
  Stats: 65 lines in 15 files changed: 27 ins; 0 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294

PR: https://git.openjdk.java.net/jdk/pull/294

From aph at redhat.com  Tue Sep 22 08:49:44 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 22 Sep 2020 09:49:44 +0100
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent
In-Reply-To: <85tuvqa8fo.fsf@nicgas01-pc.shanghai.arm.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
 <4d250323-bffa-3d73-6ca7-de9190cf559e@redhat.com>
 <85tuvqa8fo.fsf@nicgas01-pc.shanghai.arm.com>
Message-ID: <538f0144-dbe1-92b7-af3b-5da86f7c4e80@redhat.com>

On 22/09/2020 02:47, Nick Gasson wrote:
> On 09/21/20 18:23 pm, Andrew Haley wrote:
>>
>> We only need the trailing membar if is_c1_or_interpreter_only(). Otherwise
>> all volatile loads in C1 are preceded by a leading membar() so we don't
>> need a trailing one as well.
>
> Yes, OK. But the same applies to LIR_Assembler::casw() and casl().
> Should I change those as well? I don't see any reason for them to be
> different.

Neither do I, but I'd rather you didn't touch anything that wasn't
broken.

The history is a little untidy: to begin with I thought we'd be able
to use ldar/stlr instructions as intended by Arm to provide a
fully-sequentially- consistent set of operations, but it became clear
that assumptions about memory fences were so baked into C1 that it'd
be too disruptive to fix.

[ Originally cas used ldaxr;stlxr. On Feb 14 2014 I changed it to be
membar;ldxr;stxr;membar. On April 1 (!) 2014 to ldaxr;stxr;membar. On
Apr 10 2014 to ldaxr;stlxr;membar. This was a the result of much
toing-and-froing with various people, including Arm. ]

Given that we now have a membar in C1 before a volatile load when
needed for compatibility with C2, I don't believe we also need the
trailing membars after volatile stores.

However, I also don't believe that removing them is worth the effort
and risk. But that isn't the same as saying we should start *adding*
unnecessary membars now. C1 performance isn't critical, but stability
is.

>>>> 462 // By default, this operation has relaxed memory ordering
>>
>> No, it has whatever memory ordering you tell it. Plus, if you pass
>> both acquire and release, sequential consistency.
>
> If volatile load is implemented as "ldr ; dmb ishld" then this function
> alone doesn't provide sequential consistency even with acquire and
> release both set. That's why the original comment is misleading.

I see.

> Can you suggest an alternate wording here? Perhaps we can delete all
> mention of memory ordering and leave it up to the reader.

Perhaps so.

-- 
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 ngasson at openjdk.java.net  Tue Sep 22 09:55:56 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 22 Sep 2020 09:55:56 GMT
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent [v2]
In-Reply-To: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
Message-ID: <yANRqCYyRWZY4F0cAQzTHhD3JxUdbKDGQQHI7iA8VHg=.e0ba11a0-37ff-4f37-a46a-87b4242671d8@github.com>

> C1 atomic operations are supposed to be sequentially consistent by
> default but the variant in the Shenandoah C1 barrier set assembler only
> provides a half-barrier when the CAS succeeds. Added a trailing full
> barrier and load-acquire to exactly match the non-Shenandoah C1 CAS
> implementation. This prevents any memory accesses following the CAS
> operation being observed before it.
> 
> Also adjusted the documentation for ShenandoahBarrierSetAssembler
> ::cmpxchg_oop as it currently claims to be sequentially consistent by
> default but it's not clear what the "default" values of acquire and
> release should be, and the comment for acquire/release implies to me
> that setting them to true would relax the ordering guarantees but
> actually it's the opposite. I tried to simplify this and make it less
> ambiguous.
> 
> One other thing I noticed when reading this: the comment
> 
>    // Step 4. CAS has failed because the value most recently fetched
>    // from addr (which is now held in tmp1) ...
> 
> is wrong on non-LSE systems because tmp1 is rscratch1 and that is
> clobbered by the call to __ cmpxchg() at the end of step3. Although it
> doesn't matter because the value in tmp1 is not used after that point.
> Adjusted the comment to clarify this.
> 
> Tested hotspot_all_no_apps, jdk_core plus jcstress with -jvmArgs
> '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'.

Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:

  Only insert trailing barrier when is_c1_or_interpreter_only()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/280/files
  - new: https://git.openjdk.java.net/jdk/pull/280/files/4768d96f..d2358620

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=280&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=280&range=00-01

  Stats: 25 lines in 2 files changed: 8 ins; 12 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/280.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/280/head:pull/280

PR: https://git.openjdk.java.net/jdk/pull/280

From nick.gasson at arm.com  Tue Sep 22 10:06:43 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Tue, 22 Sep 2020 18:06:43 +0800
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent
In-Reply-To: <538f0144-dbe1-92b7-af3b-5da86f7c4e80@redhat.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
 <4d250323-bffa-3d73-6ca7-de9190cf559e@redhat.com>
 <85tuvqa8fo.fsf@nicgas01-pc.shanghai.arm.com>
 <538f0144-dbe1-92b7-af3b-5da86f7c4e80@redhat.com>
Message-ID: <85r1qu9lcc.fsf@nicgas01-pc.shanghai.arm.com>

On 09/22/20 16:49 pm, Andrew Haley wrote:
>
> The history is a little untidy: to begin with I thought we'd be able
> to use ldar/stlr instructions as intended by Arm to provide a
> fully-sequentially- consistent set of operations, but it became clear
> that assumptions about memory fences were so baked into C1 that it'd
> be too disruptive to fix.
>
> [ Originally cas used ldaxr;stlxr. On Feb 14 2014 I changed it to be
> membar;ldxr;stxr;membar. On April 1 (!) 2014 to ldaxr;stxr;membar. On
> Apr 10 2014 to ldaxr;stlxr;membar. This was a the result of much
> toing-and-froing with various people, including Arm. ]
>
> Given that we now have a membar in C1 before a volatile load when
> needed for compatibility with C2, I don't believe we also need the
> trailing membars after volatile stores.
>
> However, I also don't believe that removing them is worth the effort
> and risk. But that isn't the same as saying we should start *adding*
> unnecessary membars now. C1 performance isn't critical, but stability
> is.

I see, thanks for the explanation. I've added the
is_c1_or_interpreter_only() check with a comment to explain why and
edited the documentation for cmpxchg_oop() a bit more. Hopefully the bot
will post the new webrev link...

--
Thanks,
Nick

From nick.gasson at arm.com  Tue Sep 22 01:47:55 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Tue, 22 Sep 2020 09:47:55 +0800
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent
In-Reply-To: <4d250323-bffa-3d73-6ca7-de9190cf559e@redhat.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
 <4d250323-bffa-3d73-6ca7-de9190cf559e@redhat.com>
Message-ID: <85tuvqa8fo.fsf@nicgas01-pc.shanghai.arm.com>

On 09/21/20 18:23 pm, Andrew Haley wrote:
>
> We only need the trailing membar if is_c1_or_interpreter_only(). Otherwise
> all volatile loads in C1 are preceded by a leading membar() so we don't
> need a trailing one as well.

Yes, OK. But the same applies to LIR_Assembler::casw() and casl().
Should I change those as well? I don't see any reason for them to be
different.

>
>>> 462 // By default, this operation has relaxed memory ordering
>
> No, it has whatever memory ordering you tell it. Plus, if you pass
> both acquire and release, sequential consistency.

If volatile load is implemented as "ldr ; dmb ishld" then this function
alone doesn't provide sequential consistency even with acquire and
release both set. That's why the original comment is misleading.

Can you suggest an alternate wording here? Perhaps we can delete all
mention of memory ordering and leave it up to the reader.

--
Thanks,
Nick

From rkennke at openjdk.java.net  Tue Sep 22 10:09:49 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 22 Sep 2020 10:09:49 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner [v2]
In-Reply-To: <ypjKa2lXMpxUImcJjw0MxH8n1bUqOXwYCzB3lOEVt9o=.6f0bfd0f-a0f7-4677-b34c-71b64664f16d@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
 <ypjKa2lXMpxUImcJjw0MxH8n1bUqOXwYCzB3lOEVt9o=.6f0bfd0f-a0f7-4677-b34c-71b64664f16d@github.com>
Message-ID: <PHiusGAm_wvLhhTeIYrNGP9GAbi9Ic4ulYpKrJHL-Sw=.6124f840-1d98-4ef4-a9bc-fa4107ea9763@github.com>

On Mon, 21 Sep 2020 20:08:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
>> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
>> Test:
>>   hotspot_gc_shenandoah
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need to mark on-stack CLD

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 196:

> 194: }
> 195:
> 196: void ShenandoahRootScanner::roots_do(uint worker_id, OopClosure* oops, CLDClosure* clds, CodeBlobClosure* code,
> ThreadClosure *tc) {

You're still passing a (NULL) CLDClosure here, but it's not used. Or am I missing something? The method argument could
be eliminated altogether.

-------------

PR: https://git.openjdk.java.net/jdk/pull/286

From zgu at openjdk.java.net  Tue Sep 22 12:59:48 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 22 Sep 2020 12:59:48 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner [v3]
In-Reply-To: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
Message-ID: <OwRhfeq9FPl5Or__tDavNKa6h9tNILzOgitCEjpyVyI=.9bd7dbb6-b459-4cde-b214-d3938909c2ef@github.com>

> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
> Test:
>   hotspot_gc_shenandoah

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused CLD closure

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/286/files
  - new: https://git.openjdk.java.net/jdk/pull/286/files/66492e4f..2b40913b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=286&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=286&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/286/head:pull/286

PR: https://git.openjdk.java.net/jdk/pull/286

From rkennke at openjdk.java.net  Tue Sep 22 12:59:49 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 22 Sep 2020 12:59:49 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner [v3]
In-Reply-To: <OwRhfeq9FPl5Or__tDavNKa6h9tNILzOgitCEjpyVyI=.9bd7dbb6-b459-4cde-b214-d3938909c2ef@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
 <OwRhfeq9FPl5Or__tDavNKa6h9tNILzOgitCEjpyVyI=.9bd7dbb6-b459-4cde-b214-d3938909c2ef@github.com>
Message-ID: <RG4Wo-iHDDYfdk9cR-A8AA8j-CkTJiO5dtshuN_vs10=.f22f3b97-5c7c-4069-af4f-53666a5c267d@github.com>

On Tue, 22 Sep 2020 12:56:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
>> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
>> Test:
>>   hotspot_gc_shenandoah
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused CLD closure

Looks good to me now! Thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/286

From zgu at openjdk.java.net  Tue Sep 22 12:59:49 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 22 Sep 2020 12:59:49 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner [v2]
In-Reply-To: <PHiusGAm_wvLhhTeIYrNGP9GAbi9Ic4ulYpKrJHL-Sw=.6124f840-1d98-4ef4-a9bc-fa4107ea9763@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
 <ypjKa2lXMpxUImcJjw0MxH8n1bUqOXwYCzB3lOEVt9o=.6f0bfd0f-a0f7-4677-b34c-71b64664f16d@github.com>
 <PHiusGAm_wvLhhTeIYrNGP9GAbi9Ic4ulYpKrJHL-Sw=.6124f840-1d98-4ef4-a9bc-fa4107ea9763@github.com>
Message-ID: <cvez5okdWJe3TcsgV-0SVo_094DYM2X17GjchKzeibk=.467a7af8-ca6e-4732-87ea-ae9e7cb3e438@github.com>

On Tue, 22 Sep 2020 10:07:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No need to mark on-stack CLD
>
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 196:
> 
>> 194: }
>> 195:
>> 196: void ShenandoahRootScanner::roots_do(uint worker_id, OopClosure* oops, CLDClosure* clds, CodeBlobClosure* code,
>> ThreadClosure *tc) {
> 
> You're still passing a (NULL) CLDClosure here, but it's not used. Or am I missing something? The method argument could
> be eliminated altogether.

It is unused, removed.

Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/286

From kim.barrett at oracle.com  Tue Sep 22 13:14:58 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 22 Sep 2020 09:14:58 -0400
Subject: RFR: 8247912: Make narrowOop a scoped enum
In-Reply-To: <QT2zMafa6XgnfdR0r6oVSTijc98N0i1EJoiy628I67w=.3d2a3e77-7a0b-42b8-85e2-f36df1915d9f@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <QT2zMafa6XgnfdR0r6oVSTijc98N0i1EJoiy628I67w=.3d2a3e77-7a0b-42b8-85e2-f36df1915d9f@github.com>
Message-ID: <F4F6395C-EA32-4A04-A962-371939F41C4B@oracle.com>

> On Sep 21, 2020, at 5:32 PM, Ioi Lam <iklam at openjdk.java.net> wrote:
> 
> On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> 
>> Please review this change to the type narrowOop from a typedef for juint to a
>> scoped enum with uint32_t as the representation type.  This provides stronger
>> type checking when using this type.
>> [?]
> 
> This looks good overall to me.
> 
> src/hotspot/share/oops/compressedOops.hpp line 142:
> 
>> 140:     // Shift by 32 is UB if size in bits of i is 32, e.g. on 32bit platform.
>> 141:     assert(((i >> 16) >> 16) == 0, "narrowOop overflow");
>> 142:     return static_cast<narrowOop>(static_cast<NarrowType>(i));
> 
> Should we have an assert that further restricts the range according to max heap size?

I?m updating this, in part in light of your question below.

> Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be
> flagged.

It turns out we can?t restrict it to unsigned types, at least not very easily.  For example,
CDS calls this with an intptr_t value.  I suppose CDS could do conversion itself before
calling this, but that seems a little odd.  And I don?t know how many more there are after
changing that one.  

> Changes requested by iklam (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/273



From kim.barrett at oracle.com  Tue Sep 22 13:16:36 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 22 Sep 2020 09:16:36 -0400
Subject: RFR: 8247912: Make narrowOop a scoped enum
In-Reply-To: <wdW2sHqWb01hda4tJYu4J3rXaAxx05dLGRudJYVqWQ8=.d5a0a77b-ab36-4cbc-9f0a-fa535b3d0020@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <wdW2sHqWb01hda4tJYu4J3rXaAxx05dLGRudJYVqWQ8=.d5a0a77b-ab36-4cbc-9f0a-fa535b3d0020@github.com>
Message-ID: <B88F6068-58A2-4B64-8318-AE0341A5C1A7@oracle.com>

> On Sep 21, 2020, at 5:44 PM, Ioi Lam <iklam at openjdk.java.net> wrote:
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179:
> 
>> 177:     // Move narrow OOP
>> 178:     narrowOop noop = CompressedOops::encode((oop)o);
>> 179:     CompressedOops::NarrowType n = CompressedOops::narrow_oop_value(noop);
> 
> I think a public NarrowType is confusing (vs narrowOop). Since NarrowType is rarely used, and it's unlikely to be
> changed from uint32_t, maybe we should make NarrowType private, and change the above to uint32_t n =
> CompressedOops::encode_as_uint32_t((oop)o); Code that does arithmetic operations on the integer value probably wants to
> know the exact type anyway. I.e., not knowing whether NarrowType is signed or not makes me worry about the correctness
> of `n >> 16` below.

Coleen didn?t like NarrowType either.  I?m convinced by your argument that callers need to
know it?s uint32_t anyway, and will remove it.


From kbarrett at openjdk.java.net  Tue Sep 22 13:43:54 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 22 Sep 2020 13:43:54 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - improve assertion
 - remove NarrowType

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/273/files
  - new: https://git.openjdk.java.net/jdk/pull/273/files/10f9cf5f..e36f7895

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=00-01

  Stats: 10 lines in 3 files changed: 2 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273

PR: https://git.openjdk.java.net/jdk/pull/273

From mbaesken at openjdk.java.net  Tue Sep 22 14:07:26 2020
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 22 Sep 2020 14:07:26 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <QT2zMafa6XgnfdR0r6oVSTijc98N0i1EJoiy628I67w=.3d2a3e77-7a0b-42b8-85e2-f36df1915d9f@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <QT2zMafa6XgnfdR0r6oVSTijc98N0i1EJoiy628I67w=.3d2a3e77-7a0b-42b8-85e2-f36df1915d9f@github.com>
Message-ID: <NInr8Fosj_TTLJ4MOmqBUW0QWwcq42z18LFpqO6JD6k=.4d19b8a9-cb93-4b5c-bab0-74f0bee46716@github.com>

On Mon, 21 Sep 2020 21:29:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - improve assertion
>>  - remove NarrowType
>
> This looks good overall to me.

Our nightly builds+tests  on linux ppc64(le) with your change included looked good,  seems your change did not cause
any harm.  My local  build on linux s390x with your patch included  worked nicely too, some small  smoke tests were
okay as well .

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From zgu at openjdk.java.net  Tue Sep 22 14:13:23 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 22 Sep 2020 14:13:23 GMT
Subject: RFR: 8253434: Shenandoah: Cleanup ShenandoahRootScanner [v4]
In-Reply-To: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
Message-ID: <5FGdEK-Tg8cUHMbyuyIuhoN5V7PfxkVQKD2EE0CMkPY=.93e0e4a5-a1f9-44bc-a80c-f4c07ae293dd@github.com>

> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
> Test:
>   hotspot_gc_shenandoah

Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains four commits:

 - Merge master
 - Remove unused CLD closure
 - No need to mark on-stack CLD
 - Trim ShenandoahRootScanner

-------------

Changes: https://git.openjdk.java.net/jdk/pull/286/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=286&range=03
  Stats: 44 lines in 3 files changed: 2 ins; 37 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/286/head:pull/286

PR: https://git.openjdk.java.net/jdk/pull/286

From zgu at openjdk.java.net  Tue Sep 22 14:13:24 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 22 Sep 2020 14:13:24 GMT
Subject: Integrated: 8253434: Shenandoah: Cleanup ShenandoahRootScanner
In-Reply-To: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
References: <0kZ4McGIuUULxYWyThE2GPVjtSbare8nKBrNxgDSVLk=.96f2b2b4-83dd-4b8b-989a-acf7796e9b6a@github.com>
Message-ID: <OPqSafMXSbZDC1olLeTg1zvFjm04XdWVg-MFwIvBnN8=.ecafb902-3ab2-4ab1-aeda-01425ff46987@github.com>

On Mon, 21 Sep 2020 18:11:10 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> After moving CLDG mark to concurrent phase, ShenandoahRootScanner::strong_roots_do() and
> ShenandoahRootScanner::roots_do() are practical the same, let's trim one.
> Test:
>   hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 3d5fea1f
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d5fea1f
Stats:     42 lines in 3 files changed: 35 ins; 0 del; 7 mod

8253434: Shenandoah: Cleanup ShenandoahRootScanner

Reviewed-by: rkennke

-------------

PR: https://git.openjdk.java.net/jdk/pull/286

From iklam at openjdk.java.net  Tue Sep 22 15:41:36 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 22 Sep 2020 15:41:36 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
Message-ID: <MeZOuoe1unkK3ZYtNhc2ODqvDBYYGUoEOmaHGGosocw=.83d43d8c-d653-48b0-87b1-e996209de3ae@github.com>

On Tue, 22 Sep 2020 13:43:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the type narrowOop from a typedef for juint to a
>> scoped enum with uint32_t as the representation type.  This provides stronger
>> type checking when using this type.
>> 
>> For the most part this was fairly straightforward, and the patch size is
>> relatively small.  The implementation of some existing CompressedOops
>> "primitives" required adjustment. An explicit conversion to narrowOop was
>> added, with casts change to use it.  There were a few places that were type
>> punning and needed explicit conversions,, mostly in platform-specific assembly
>> support.
>> 
>> There are a couple of lingering problems.
>> 
>> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
>> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
>> this probably ought to be done differently.
>> 
>> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
>> whether these can be safely converted to CompressedOops::narrow_oop_cast.
>> 
>> There might still be some casts from narrowOop to an integral type.  Those are
>> hard to find in our cast-happy code base.
>> 
>> Testing:
>> tier1-6 for Oracle supported platforms.
>> Build fastdebug linux-ppc64le and linux-s390x.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - improve assertion
>  - remove NarrowType

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From iklam at openjdk.java.net  Tue Sep 22 15:47:46 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 22 Sep 2020 15:47:46 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <MeZOuoe1unkK3ZYtNhc2ODqvDBYYGUoEOmaHGGosocw=.83d43d8c-d653-48b0-87b1-e996209de3ae@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
 <MeZOuoe1unkK3ZYtNhc2ODqvDBYYGUoEOmaHGGosocw=.83d43d8c-d653-48b0-87b1-e996209de3ae@github.com>
Message-ID: <YuLb1saqpS3gnn8FJ2UXnjDEHU0qYfFcJImutdcfAa0=.0e035ddb-ef64-41ff-95f3-2845036dab57@github.com>

On Tue, 22 Sep 2020 15:38:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - improve assertion
>>  - remove NarrowType
>
> Marked as reviewed by iklam (Reviewer).

> > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be
> > flagged.
> 
> It turns out we can't restrict it to unsigned types, at least not very easily. For example,
> CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before
> calling this, but that seems a little odd. And I don't know how many more there are after
> changing that one.

But shouldn't intptr_t be unsigned? I tested with this:

#include <type_traits>
#include <stdio.h>

int main() {
  printf("%d %d\n", std::is_signed<int>::value, std::is_signed<int*>::value);
}

and it prints out "1 0".

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From zgu at openjdk.java.net  Tue Sep 22 16:15:41 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 22 Sep 2020 16:15:41 GMT
Subject: RFR: 8253481: Shenandoah: ShenandoahConcurrentRootScanner::oops_do()
 should always use _claim_strong for CLDClosure
Message-ID: <R0v5uAwUn6Uwprhlus3zNKGMhNhoQ-pRWYsnlPdAfFk=.0bff02a7-3f9e-49a0-b74e-0b767ac9d6fb@github.com>

_claim_none should only be used for single thread scanning, regardless concurrent or not.

 ShenandoahConcurrentRootScanner declares ShenandoahClassLoaderDataRoots multi-thread capable, so should always use
 _claim_strong for scanning CLDG.

This is not a correctness bug. _claim_none results CLDG to be scanned by every worker.

Test:
  - [x] hotspot_gc_shenandoah

-------------

Commit messages:
 - 8253481: Shenandoah: ShenandoahConcurrentRootScanner::oops_do() should always use _claim_strong for CLDClosure

Changes: https://git.openjdk.java.net/jdk/pull/304/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=304&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253481
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/304.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/304/head:pull/304

PR: https://git.openjdk.java.net/jdk/pull/304

From erikj at openjdk.java.net  Tue Sep 22 17:02:59 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Sep 2020 17:02:59 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]
In-Reply-To: <k0i1glu5zv2pPnRHqDCGkTCvMW5tA1rWUhW0tMPLmfs=.b3ea3c93-7ecd-4aee-9218-0df755df6fef@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <axvLamk-3k-CVBfcyN0Nc59o1619WwmDwm4wweMX2M4=.1fa21044-7b40-4107-abb3-ccd40b0fd923@github.com>
 <RN3cacKvAfMGjCpxdH2mdvPJH9XwKmAIUCDtNzgFpMw=.7060b196-467f-4ae2-b527-7f5bf938ab8f@github.com>
 <k0i1glu5zv2pPnRHqDCGkTCvMW5tA1rWUhW0tMPLmfs=.b3ea3c93-7ecd-4aee-9218-0df755df6fef@github.com>
Message-ID: <D91wL0sbP_n44Xg5gXaGvsxST1XcOkukEMVKXUoAIBQ=.eb8db5f0-82e4-4d53-bcd5-afb0a567c3b5@github.com>

On Mon, 21 Sep 2020 07:10:47 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> I assume you need the rest of the PATH on Windows.
>
>> I assume you need the rest of the PATH on Windows.
> 
> Doesn't look like it actually. I've reverted it, thanks for catching it.

Thanks, I tried the updated patch and it works now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From mbeckwit at openjdk.java.net  Tue Sep 22 18:38:11 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 22 Sep 2020 18:38:11 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v4]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <9AWXqWBreFSnBvXc9kzj0R7RIIRjmdg3nDz859KKD5Q=.df3d538f-a8d7-4e22-8d8c-76371172f75d@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 13 commits:

 - 8248787: G1: Workaround MSVC bug
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248670: Windows: Exception handling support on AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248660: AArch64: Make _clear_cache and _nop portable
   Summary: __builtin___clear_cache, etc.
   Contributed-by: mbeckwit, luhenry, burban
 - 8248659: AArch64: Extend CPU Feature detection
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248656: Add Windows AArch64 platform support code
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248498: Add build system support for Windows AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248663: AArch64: Avoid existing macros/keywords of MSVC
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248676: AArch64: Add workaround for LITable constructor
   Reviewed-by: aph
   Contributed-by: mbeckwit, luhenry, burban
 - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests)
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/7b860120...50ab8edf

-------------

Changes: https://git.openjdk.java.net/jdk/pull/212/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=03
  Stats: 2970 lines in 69 files changed: 2407 ins; 275 del; 288 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From zgu at openjdk.java.net  Tue Sep 22 18:49:50 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 22 Sep 2020 18:49:50 GMT
Subject: RFR: 8253493: Shenandoah: Remove ShenandoahSerialRoot definition
Message-ID: <z8r6Q4BnStGq6xpNz2VGFNAN3HFdbkE6l0AVYIXYT3s=.155da721-4d95-4901-acff-bc49d91529a8@github.com>

JDK-8247281 removed ShenandoahSerialRoot's implementation and uses, but not its definition.

-------------

Commit messages:
 - 8253493: Shenandoah: Remove ShenandoahSerialRoot definition

Changes: https://git.openjdk.java.net/jdk/pull/307/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=307&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253493
  Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/307.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/307/head:pull/307

PR: https://git.openjdk.java.net/jdk/pull/307

From rkennke at openjdk.java.net  Tue Sep 22 19:04:11 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 22 Sep 2020 19:04:11 GMT
Subject: RFR: 8253493: Shenandoah: Remove ShenandoahSerialRoot definition
In-Reply-To: <z8r6Q4BnStGq6xpNz2VGFNAN3HFdbkE6l0AVYIXYT3s=.155da721-4d95-4901-acff-bc49d91529a8@github.com>
References: <z8r6Q4BnStGq6xpNz2VGFNAN3HFdbkE6l0AVYIXYT3s=.155da721-4d95-4901-acff-bc49d91529a8@github.com>
Message-ID: <5XvahQL6iRxn5l50DI70S1fdI-B2-ePRSW1VcXIYh60=.557fcb72-d88a-4273-899d-2c055ec1fba8@github.com>

On Tue, 22 Sep 2020 18:43:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8247281 removed ShenandoahSerialRoot's implementation and uses, but not its definition.

Looks good to me, thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/307

From zgu at openjdk.java.net  Tue Sep 22 19:45:13 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 22 Sep 2020 19:45:13 GMT
Subject: Integrated: 8253493: Shenandoah: Remove ShenandoahSerialRoot
 definition
In-Reply-To: <z8r6Q4BnStGq6xpNz2VGFNAN3HFdbkE6l0AVYIXYT3s=.155da721-4d95-4901-acff-bc49d91529a8@github.com>
References: <z8r6Q4BnStGq6xpNz2VGFNAN3HFdbkE6l0AVYIXYT3s=.155da721-4d95-4901-acff-bc49d91529a8@github.com>
Message-ID: <smq2ZBEe1T_FhPD62WbPe0E4t_neIQfxIkhuMqaD_mQ=.a1bd9e51-1176-4648-8c76-6c7343a9c535@github.com>

On Tue, 22 Sep 2020 18:43:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8247281 removed ShenandoahSerialRoot's implementation and uses, but not its definition.

This pull request has now been integrated.

Changeset: 581f0f26
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/581f0f26
Stats:     15 lines in 1 file changed: 15 ins; 0 del; 0 mod

8253493: Shenandoah: Remove ShenandoahSerialRoot definition

Reviewed-by: rkennke

-------------

PR: https://git.openjdk.java.net/jdk/pull/307

From amenkov at openjdk.java.net  Tue Sep 22 22:57:49 2020
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 22 Sep 2020 22:57:49 GMT
Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot
Message-ID: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>

This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate
issue for it: JDK-8253371)

In most tests just "@requires vm.jvmti" is added,
in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has
JVMTI included)

-------------

Commit messages:
 - 8253372: [TESTBUG] update tests which require jvmti - hotspot

Changes: https://git.openjdk.java.net/jdk/pull/314/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=314&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253372
  Stats: 38 lines in 36 files changed: 25 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/314.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/314/head:pull/314

PR: https://git.openjdk.java.net/jdk/pull/314

From cjplummer at openjdk.java.net  Tue Sep 22 23:10:37 2020
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 22 Sep 2020 23:10:37 GMT
Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot
In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
Message-ID: <_wP0b5uSUa6fQ23NaIK5RsUj_dZnoda3L_OOxxL6CbI=.ff626b36-a833-4ad0-966f-82994942b2bc@github.com>

On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate
> issue for it: JDK-8253371)
> In most tests just "@requires vm.jvmti" is added,
> in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has
> JVMTI included)

How did you determine the list of tests that need jvmti?

-------------

PR: https://git.openjdk.java.net/jdk/pull/314

From iklam at openjdk.java.net  Tue Sep 22 23:38:46 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 22 Sep 2020 23:38:46 GMT
Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot
In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
Message-ID: <F0wkaYEch4Mj1zN_38lJMK1lLdhO1A4Ct5VmzDanm3Y=.d904a1c8-55ec-41c8-af56-b09f03512fac@github.com>

On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate
> issue for it: JDK-8253371)
> In most tests just "@requires vm.jvmti" is added,
> in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has
> JVMTI included)

The CDS test changes look good to me. Thanks for doing this.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/314

From sspitsyn at openjdk.java.net  Tue Sep 22 23:38:46 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 22 Sep 2020 23:38:46 GMT
Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot
In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
Message-ID: <aUbjD9e3Apt0LWewF2-r2-HV7w6sdOP3StH3moYcXpc=.a7b96a6f-7745-41b5-b0db-438abbda85a3@github.com>

On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate
> issue for it: JDK-8253371)
> In most tests just "@requires vm.jvmti" is added,
> in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has
> JVMTI included)

Alex, It looks good.
Did you test it in minimal config?

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/314

From adityam at openjdk.java.net  Wed Sep 23 01:13:09 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Wed, 23 Sep 2020 01:13:09 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <XOwP2cI09hJOnnbsDmyth_3leqKHNW4Lw4N2obc6bOY=.dda906a6-c571-4b63-b986-433c23a8e659@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <u8BbI6NmtA161jnA4wVKc8vU7ANIy2uWcQ1duQjVlBo=.f94d86da-8f74-42d9-b148-d1c7c2c414e5@github.com>
 <brs1Xp_RGGIYgGZQ0dXs75PenKba_2uMuOKolkowQ3E=.dc0b4d85-d731-41eb-9be6-ff55b96a240e@github.com>
 <XOwP2cI09hJOnnbsDmyth_3leqKHNW4Lw4N2obc6bOY=.dda906a6-c571-4b63-b986-433c23a8e659@github.com>
Message-ID: <ZrPajyW-9vM46owonILKehMRxpM3TPaPbAYqmwp8jeY=.f9e146bf-cbfb-4a27-9687-6e23de9d5908@github.com>

On Wed, 16 Sep 2020 06:38:14 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> @fisk Good point. It's clear that the field_addr and base ones can be changed, and I'll do that in the next update I
>> send. I'll take a closer look at the marking functions you mentioned as well. I want to understand the decorators
>> they're using and see whether they still do anything meaningful before I get rid of them.
>
> The only supported decorators for primitives is memory ordering decorators. These functions use MO_RELAXED. Specifying
> MO_RELAXED is equivalent to using Atomic::load/store.

@fisk Thanks again for the feedback, and sorry for the delay (it's been a very busy week!). I've pushed an update that
cleans up a bunch of the `_raw` stuff.

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From adityam at openjdk.java.net  Wed Sep 23 01:13:08 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Wed, 23 Sep 2020 01:13:08 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
Message-ID: <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>

> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
> removed, and callers have been modified.  Testing done:
> tier1
> hotspot_gc_shenandoah

Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The incremental
webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits
since the last revision:

 - Remove redundant _raw functions.
 - 8251358: Clean up Access configuration after Shenandoah barrier change

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/146/files
  - new: https://git.openjdk.java.net/jdk/pull/146/files/df595b28..45d77581

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=146&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=146&range=00-01

  Stats: 24516 lines in 666 files changed: 12969 ins; 8897 del; 2650 mod
  Patch: https://git.openjdk.java.net/jdk/pull/146.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/146/head:pull/146

PR: https://git.openjdk.java.net/jdk/pull/146

From shade at openjdk.java.net  Wed Sep 23 05:48:14 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Sep 2020 05:48:14 GMT
Subject: RFR: 8253481: Shenandoah:
 ShenandoahConcurrentRootScanner::oops_do() should always use _claim_strong
 for CLDClosure
In-Reply-To: <R0v5uAwUn6Uwprhlus3zNKGMhNhoQ-pRWYsnlPdAfFk=.0bff02a7-3f9e-49a0-b74e-0b767ac9d6fb@github.com>
References: <R0v5uAwUn6Uwprhlus3zNKGMhNhoQ-pRWYsnlPdAfFk=.0bff02a7-3f9e-49a0-b74e-0b767ac9d6fb@github.com>
Message-ID: <JDlBhsknUEhc9LEeyy1pteYlA-njPFPak1ERWcwm3KM=.077ecb19-0069-4c84-9c23-46644f79a3fc@github.com>

On Tue, 22 Sep 2020 16:08:11 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> _claim_none should only be used for single thread scanning, regardless concurrent or not.
> 
>  ShenandoahConcurrentRootScanner declares ShenandoahClassLoaderDataRoots multi-thread capable, so should always use
>  _claim_strong for scanning CLDG.
> 
> This is not a correctness bug. _claim_none results CLDG to be scanned by every worker.
> 
> Test:
>   - [x] hotspot_gc_shenandoah

Please see JDK-8246097 and JDK-8246101 for previous experiments in this area.

-------------

PR: https://git.openjdk.java.net/jdk/pull/304

From zgu at openjdk.java.net  Wed Sep 23 11:35:42 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 23 Sep 2020 11:35:42 GMT
Subject: RFR: 8253481: Shenandoah:
 ShenandoahConcurrentRootScanner::oops_do() should always use _claim_strong
 for CLDClosure
In-Reply-To: <JDlBhsknUEhc9LEeyy1pteYlA-njPFPak1ERWcwm3KM=.077ecb19-0069-4c84-9c23-46644f79a3fc@github.com>
References: <R0v5uAwUn6Uwprhlus3zNKGMhNhoQ-pRWYsnlPdAfFk=.0bff02a7-3f9e-49a0-b74e-0b767ac9d6fb@github.com>
 <JDlBhsknUEhc9LEeyy1pteYlA-njPFPak1ERWcwm3KM=.077ecb19-0069-4c84-9c23-46644f79a3fc@github.com>
Message-ID: <tdx6LskOqHZdGBJu9uJg1xRVZORhhpRzZgZ9i-YisbM=.c231e83e-88b9-4a04-8621-d2f0ea7f5226@github.com>

On Wed, 23 Sep 2020 05:45:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> _claim_none should only be used for single thread scanning, regardless concurrent or not.
>> 
>>  ShenandoahConcurrentRootScanner declares ShenandoahClassLoaderDataRoots multi-thread capable, so should always use
>>  _claim_strong for scanning CLDG.
>> 
>> This is not a correctness bug. _claim_none results CLDG to be scanned by every worker.
>> 
>> Test:
>>   - [x] hotspot_gc_shenandoah
>
> Please see JDK-8246097 and JDK-8246101 for previous experiments in this area.

Make a dup of JDK-8246101

-------------

PR: https://git.openjdk.java.net/jdk/pull/304

From zgu at openjdk.java.net  Wed Sep 23 11:35:42 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 23 Sep 2020 11:35:42 GMT
Subject: Withdrawn: 8253481: Shenandoah:
 ShenandoahConcurrentRootScanner::oops_do() should always use _claim_strong
 for CLDClosure
In-Reply-To: <R0v5uAwUn6Uwprhlus3zNKGMhNhoQ-pRWYsnlPdAfFk=.0bff02a7-3f9e-49a0-b74e-0b767ac9d6fb@github.com>
References: <R0v5uAwUn6Uwprhlus3zNKGMhNhoQ-pRWYsnlPdAfFk=.0bff02a7-3f9e-49a0-b74e-0b767ac9d6fb@github.com>
Message-ID: <46HafQGMkNfsCQFenjLNtxxkazmQNKtN7i2dSaZfjyo=.ea21e79d-c92b-482f-b1e7-0951d7864f21@github.com>

On Tue, 22 Sep 2020 16:08:11 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> _claim_none should only be used for single thread scanning, regardless concurrent or not.
> 
>  ShenandoahConcurrentRootScanner declares ShenandoahClassLoaderDataRoots multi-thread capable, so should always use
>  _claim_strong for scanning CLDG.
> 
> This is not a correctness bug. _claim_none results CLDG to be scanned by every worker.
> 
> Test:
>   - [x] hotspot_gc_shenandoah

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/304

From rkennke at openjdk.java.net  Wed Sep 23 11:56:41 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 23 Sep 2020 11:56:41 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
Message-ID: <Jk8pktKlbjWrlWsPMOdImPZh9SXnNabK01VayjICfz0=.7c1224f3-7ee5-47c6-bb01-2c2cf4b15111@github.com>

On Wed, 23 Sep 2020 01:13:08 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
>> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
>> removed, and callers have been modified.  Testing done:
>> tier1
>> hotspot_gc_shenandoah
>
> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains two commits:
>  - Remove redundant _raw functions.
>  - 8251358: Clean up Access configuration after Shenandoah barrier change

Looks good to me! Good to see those unused code paths go! Thanks!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/146

From mbeckwit at openjdk.java.net  Wed Sep 23 13:23:43 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Wed, 23 Sep 2020 13:23:43 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <IPIRqfUzHsFb8ugn81EQIFQMuWa5-dUiSIHBsMHdPc4=.e5c97057-326a-4bcb-91d5-bc0498ea5d8b@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  Update orderAccess_windows_aarch64.hpp
  
  changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/50ab8edf..4da7b89e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From mbeckwit at openjdk.java.net  Wed Sep 23 13:23:43 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Wed, 23 Sep 2020 13:23:43 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
In-Reply-To: <qURWEYTydROTURbaHd9Lw5G9BTvCkLlpD7ybgTxkycg=.77cee65f-1a42-4d00-a7f7-3a911fbfa6be@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <lJDbfp82LKTSiLLT8Mrt3OxsRcnU3cUjr6KsGfR0WDQ=.4d31921b-1d2a-46ca-942a-4ee6dd9a0040@github.com>
 <BtXRWhdTVMJd1UyIAZTtUbCxnAfM20wCvbigZvdlbDk=.87224bc2-3fe9-4790-9602-f7e8c264f31b@github.com>
 <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com>
 <eDF4lO_5Em7jD5uxcMo1Rhqnszco-Yc3Ugw676OeIos=.de33e8d4-208c-454c-836a-60f9af4e0ef1@github.com>
 <qURWEYTydROTURbaHd9Lw5G9BTvCkLlpD7ybgTxkycg=.77cee65f-1a42-4d00-a7f7-3a911fbfa6be@github.com>
Message-ID: <XCiK4un3qURo99_id7bYror-ATiT_5Bf4tzLICprwfo=.50e0b023-54eb-468e-8e2d-4165760bea2f@github.com>

On Mon, 21 Sep 2020 14:47:15 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
>>> 
>>> On 18/09/2020 11:14, Monica Beckwith wrote:
>>> 
>>> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>> 
>>> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this.
>> 
>> 
>> Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the
>> retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part
>> would look indeed nicer with that:  https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
>> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
>> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
>> @@ -13,6 +13,8 @@ class Register(Operand):
>> 
>>      def generate(self):
>>          self.number = random.randint(0, 30)
>> +        if self.number == 18:
>> +            self.number = 17
>>          return self
>> 
>>      def astr(self, prefix):
>> @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register):
>> 
>>      def generate(self):
>>          self.number = random.randint(0, 31)
>> +        if self.number == 18:
>> +            self.number = 16
>>          return self
>> 
>>      def astr(self, prefix = ""):
>> @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register):
>>  class GeneralRegisterOrSp(Register):
>>      def generate(self):
>>          self.number = random.randint(0, 31)
>> +        if self.number == 18:
>> +            self.number = 15
>>          return self
>> 
>>      def astr(self, prefix = ""):
>> @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn",   "__ ccmn(zr, zr, 3u, Assembler::LE);",
>>                          ["st1w",   "__ sve_st1w(z0, __ S, p1, Address(r0, 7));",         "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"],
>>                          ["st1b",   "__ sve_st1b(z0, __ B, p2, Address(sp, r1));",        "st1b\t{z0.b}, p2, [sp, x1]"],
>>                          ["st1h",   "__ sve_st1h(z0, __ H, p3, Address(sp, r8));",        "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"],
>> -                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r18));",       "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"],
>> +                        ["st1d",   "__ sve_st1d(z0, __ D, p4, Address(r0, r17));",       "st1d\t{z0.d}, p4, [x0, x17,
>> LSL #3]"],
>>                          ["ldr",    "__ sve_ldr(z0, Address(sp));",                       "ldr\tz0, [sp]"],
>>                          ["ldr",    "__ sve_ldr(z31, Address(sp, -256));",                "ldr\tz31, [sp, #-256, MUL VL]"],
>>                          ["str",    "__ sve_str(z8, Address(r8, 255));",                  "str\tz8, [x8, #255, MUL VL]"],
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
>> 
>> On 21/09/2020 09:18, Bernhard Urban-Forster wrote:
>> 
>> > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the
>> > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part
>> > would look indeed nicer with that:  https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
>> > [...]
>> 
>> Yes, better. Thanks.
> 
> Great, I've updated the PR. Thank you!

Thanks, Andrew for catching that. I have made the needful changes.

-Monica

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> On 18/09/2020 11:14, Monica Beckwith wrote:
> 
> > This is a continuation of
> > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
> > Changes since then:
> > * We've improved the write barrier as suggested by Andrew [1]
> 
> It's still wrong, I'm afraid. This is not a full barrier:
> 
> +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel);
> 
> it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as
> well. It might well be that you get the same DMB ISH instruction, but
> unless you use a StoreLoad barrier here it's theoretically possible
> for a compiler to reorder accesses so that a processor sees its own
> stores before other processors do. (And it's confusing for the reader
> too.)
> 
> Use:
> 
> +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst);
> 
> See here:
> 
> https://en.cppreference.com/w/cpp/atomic/memory_order
> 
> memory_order_seq_cst "...plus a single total order exists in which all
> threads observe all modifications in the same order (see
> Sequentially-consistent ordering below)"
> 
> --
> 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

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From amenkov at openjdk.java.net  Wed Sep 23 21:11:56 2020
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 23 Sep 2020 21:11:56 GMT
Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot
In-Reply-To: <aUbjD9e3Apt0LWewF2-r2-HV7w6sdOP3StH3moYcXpc=.a7b96a6f-7745-41b5-b0db-438abbda85a3@github.com>
References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
 <aUbjD9e3Apt0LWewF2-r2-HV7w6sdOP3StH3moYcXpc=.a7b96a6f-7745-41b5-b0db-438abbda85a3@github.com>
Message-ID: <jWt2a8P_xMevbvNwXhl1SgDaMazhlowwo_USWGp21X8=.e8d488ce-d94d-4ac8-9a70-dce5a0c53f4a@github.com>

On Tue, 22 Sep 2020 23:35:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> 
> Did you test it in minimal config?

Sure. The updated tests are skipped with minimal VM

-------------

PR: https://git.openjdk.java.net/jdk/pull/314

From amenkov at openjdk.java.net  Wed Sep 23 21:11:55 2020
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 23 Sep 2020 21:11:55 GMT
Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot
In-Reply-To: <F0wkaYEch4Mj1zN_38lJMK1lLdhO1A4Ct5VmzDanm3Y=.d904a1c8-55ec-41c8-af56-b09f03512fac@github.com>
References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
 <F0wkaYEch4Mj1zN_38lJMK1lLdhO1A4Ct5VmzDanm3Y=.d904a1c8-55ec-41c8-af56-b09f03512fac@github.com>
Message-ID: <xYcqTVdOXdgOY4HfYHyKkvlGdErz79AW5QH4sqG8Nnk=.bed2efa1-680b-4b42-b6ba-c7e12fae8536@github.com>

On Tue, 22 Sep 2020 23:36:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate
>> issue for it: JDK-8253371)
>> In most tests just "@requires vm.jvmti" is added,
>> in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has
>> JVMTI included)
>
> The CDS test changes look good to me. Thanks for doing this.

> 
> 
> How did you determine the list of tests that need jvmti?

I tried to run all hotspot tests, but it failed due timeout. Main reason is absence of management (management module
presents in minimal, but contains only stubs). There is a separate issue for management requirement: JDK-8252474 So I
got the list by combining 2 ways:
- search for known functionalities which require jvmti (java.instrument, javaagent/agentlib)
- run subsets of the tests and looked at the failure reasons

So I can miss some tests which need to be updated, but it will be much simpler to identify them after JDK-8252474 is
fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/314

From amenkov at openjdk.java.net  Wed Sep 23 21:14:46 2020
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 23 Sep 2020 21:14:46 GMT
Subject: Integrated: 8253372: [TESTBUG] update tests which require jvmti -
 hotspot
In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com>
Message-ID: <11WW-JcbzA7F1bLTDhj2mHHORIMm8MKjW6YiPgfqf_Y=.4a02eb5c-a1e2-4a2b-a4f2-f54dd9227133@github.com>

On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate
> issue for it: JDK-8253371)
> In most tests just "@requires vm.jvmti" is added,
> in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has
> JVMTI included)

This pull request has now been integrated.

Changeset: 3320fc0f
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3320fc0f
Stats:     38 lines in 36 files changed: 25 ins; 0 del; 13 mod

8253372: [TESTBUG] update tests which require jvmti - hotspot

Reviewed-by: sspitsyn, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/314

From adityam at openjdk.java.net  Thu Sep 24 01:00:53 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Thu, 24 Sep 2020 01:00:53 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <Jk8pktKlbjWrlWsPMOdImPZh9SXnNabK01VayjICfz0=.7c1224f3-7ee5-47c6-bb01-2c2cf4b15111@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <Jk8pktKlbjWrlWsPMOdImPZh9SXnNabK01VayjICfz0=.7c1224f3-7ee5-47c6-bb01-2c2cf4b15111@github.com>
Message-ID: <V5Fq540FcIhgQxMpAaJYMc3BD5BzSpivPDoD0PeVeVg=.0fdafca3-f2c1-4c0a-a375-c6f3faf0f626@github.com>

On Wed, 23 Sep 2020 11:53:42 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The incremental
>> webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits
>> since the last revision:
>>  - Remove redundant _raw functions.
>>  - 8251358: Clean up Access configuration after Shenandoah barrier change
>
> Looks good to me! Good to see those unused code paths go! Thanks!

Thanks @rkennke . I will also need a sponsor for this change. Can you or @fisk please do that?

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From dholmes at openjdk.java.net  Thu Sep 24 05:00:16 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Sep 2020 05:00:16 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
In-Reply-To: <IPIRqfUzHsFb8ugn81EQIFQMuWa5-dUiSIHBsMHdPc4=.e5c97057-326a-4bcb-91d5-bc0498ea5d8b@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <IPIRqfUzHsFb8ugn81EQIFQMuWa5-dUiSIHBsMHdPc4=.e5c97057-326a-4bcb-91d5-bc0498ea5d8b@github.com>
Message-ID: <vtLrgunrlk5s8YjPw7UVWcLzGYj5f2nUVjozegqW7GA=.b9fedff1-df09-4080-991f-97d32b1a02ce@github.com>

On Wed, 23 Sep 2020 13:23:43 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update orderAccess_windows_aarch64.hpp
>   
>   changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided

I've mainly looked at the non-Aarch64 specific changes. A couple of minor comments below.

src/hotspot/os/windows/os_windows.cpp line 2546:

> 2544:
> 2545: #ifdef _M_ARM64
> 2546:       // Unsafe memory access

I'm not at all clear why this unsafe memory access handling is for Aarch64 only?

src/hotspot/share/runtime/stubRoutines.cpp line 397:

> 395:   // test safefetch routines
> 396:   // Not on Windows 32bit until 8074860 is fixed
> 397: #if ! (defined(_WIN32) && defined(_M_IX86)) && !defined(_M_ARM64)

The comment needs updating to refer to Aarch64.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/212

From dholmes at openjdk.java.net  Thu Sep 24 05:14:47 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Sep 2020 05:14:47 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
In-Reply-To: <vtLrgunrlk5s8YjPw7UVWcLzGYj5f2nUVjozegqW7GA=.b9fedff1-df09-4080-991f-97d32b1a02ce@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <IPIRqfUzHsFb8ugn81EQIFQMuWa5-dUiSIHBsMHdPc4=.e5c97057-326a-4bcb-91d5-bc0498ea5d8b@github.com>
 <vtLrgunrlk5s8YjPw7UVWcLzGYj5f2nUVjozegqW7GA=.b9fedff1-df09-4080-991f-97d32b1a02ce@github.com>
Message-ID: <4-nb0OwmjwH4FpKoNor3BGZmsAKouFjMJpJ8uN62Y_s=.7de01521-af13-4ce1-ace9-80f4ef2a6d4f@github.com>

On Thu, 24 Sep 2020 04:57:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update orderAccess_windows_aarch64.hpp
>>   
>>   changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
>
> I've mainly looked at the non-Aarch64 specific changes. A couple of minor comments below.

@mo-beck This PR should not be associated with any JBS issues which are targeted at repo-aarch64-port. All such issues
should have been closed by now when the associated code was pushed to aarch64-port repo. That was the whole point of
creating separate issues so that they could be tracked in the porting repo. Now that all of that work should be
complete the only issue that should remain open in relation to the Windows-Aarch64 port is JDK-8248238. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From shade at openjdk.java.net  Thu Sep 24 06:05:56 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Sep 2020 06:05:56 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
Message-ID: <PDPOMLX9bf8jKGhOuF-ql77MSWbTF1NCAVd7PFY9aw0=.c9ebc955-f821-4dce-bdd1-1d97095309c2@github.com>

On Wed, 23 Sep 2020 01:13:08 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
>> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
>> removed, and callers have been modified.  Testing done:
>> tier1
>> hotspot_gc_shenandoah
>
> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The incremental
> webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits
> since the last revision:
>  - Remove redundant _raw functions.
>  - 8251358: Clean up Access configuration after Shenandoah barrier change

No, wait a second. I agree with some `_raw` removals, but not the other. The point of many `_raw` calls is using them
from internal GC code when we *know* barriers are not required (because GC already knows in which state the object is
in) or even correct to perform (for example, setting marks on incomplete objects). Changing e.g. `set_mark_raw` to
`set_mark` on those paths exposes objects to GC barriers.

src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp line 74:

> 72:   assert(obj_addr != destination, "everything in this pass should be moving");
> 73:   Copy::aligned_conjoint_words(obj_addr, destination, size);
> 74:   oop(destination)->init_mark();

For example, here.

src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp line 51:

> 49:           // Clear bitmap and fix mark word.
> 50:           _bitmap->clear(obj);
> 51:           obj->init_mark();

For example, here.

src/hotspot/share/gc/parallel/psPromotionLAB.cpp line 86:

> 84:   HeapWord* tlab_end = end() + filler_header_size;
> 85:   typeArrayOop filler_oop = (typeArrayOop) top();
> 86:   filler_oop->set_mark(markWord::prototype());

...or here.

-------------

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/146

From eosterlund at openjdk.java.net  Thu Sep 24 06:29:53 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Sep 2020 06:29:53 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <PDPOMLX9bf8jKGhOuF-ql77MSWbTF1NCAVd7PFY9aw0=.c9ebc955-f821-4dce-bdd1-1d97095309c2@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <PDPOMLX9bf8jKGhOuF-ql77MSWbTF1NCAVd7PFY9aw0=.c9ebc955-f821-4dce-bdd1-1d97095309c2@github.com>
Message-ID: <AtddIpp60T4wWlOcrD4_t5lXLc5natxGlxWrDb9_Bwg=.8cde7cc1-b1ec-4b73-a186-fd987047faca@github.com>

On Thu, 24 Sep 2020 06:03:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> No, wait a second. I agree with some `_raw` removals, but not the other. The point of many `_raw` calls is using them
> from internal GC code when we *know* barriers are not required (because GC already knows in which state the object is
> in) or even correct to perform (for example, setting marks on incomplete objects). Changing e.g. `set_mark_raw` to
> `set_mark` on those paths exposes objects to GC barriers.

We did not have said raw functions before Shenandoah. They were added to distinguish between barriers vs no barriers.
And people would have to figure out which one to call. Now we never use barriers, so there is no difference. Sure the
GC code knows there are no barriers. Agreed. But so does everybody else. Because we are removing barriers for
primitives support. And mark words are simply primitives. Or do you have any other need for actually having barriers on
mark word reads and writes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From shade at openjdk.java.net  Thu Sep 24 06:38:16 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Sep 2020 06:38:16 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <AtddIpp60T4wWlOcrD4_t5lXLc5natxGlxWrDb9_Bwg=.8cde7cc1-b1ec-4b73-a186-fd987047faca@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <PDPOMLX9bf8jKGhOuF-ql77MSWbTF1NCAVd7PFY9aw0=.c9ebc955-f821-4dce-bdd1-1d97095309c2@github.com>
 <AtddIpp60T4wWlOcrD4_t5lXLc5natxGlxWrDb9_Bwg=.8cde7cc1-b1ec-4b73-a186-fd987047faca@github.com>
Message-ID: <r00S1-HZhfvjStMQsQFS70Z2PCUbP7rpqsgVuNr2Yx8=.26b6a226-aeb9-4059-b2cc-302810016207@github.com>

On Thu, 24 Sep 2020 06:27:23 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> We did not have said raw functions before Shenandoah.

Right. I misremembered the history here. JDK-8199735 added these `_raw` methods and this effectively reverts it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From shade at openjdk.java.net  Thu Sep 24 06:38:16 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Sep 2020 06:38:16 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
Message-ID: <98EEPdiHGZRQuk-pxS17X2y9gE6bWwIKGQ_6cJBdW-Y=.c76cb0e8-e348-4c14-bd46-4e38af680987@github.com>

On Wed, 23 Sep 2020 01:13:08 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
>> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
>> removed, and callers have been modified.  Testing done:
>> tier1
>> hotspot_gc_shenandoah
>
> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains two commits:
>  - Remove redundant _raw functions.
>  - 8251358: Clean up Access configuration after Shenandoah barrier change

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From eosterlund at openjdk.java.net  Thu Sep 24 06:43:27 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Sep 2020 06:43:27 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <umg3i6VhtZjJxUltTLQDrT9wUGSn3IlL_6eaidyjZzI=.ba450b7e-d600-43ca-a90a-67d041baa3fc@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <98EEPdiHGZRQuk-pxS17X2y9gE6bWwIKGQ_6cJBdW-Y=.c76cb0e8-e348-4c14-bd46-4e38af680987@github.com>
 <umg3i6VhtZjJxUltTLQDrT9wUGSn3IlL_6eaidyjZzI=.ba450b7e-d600-43ca-a90a-67d041baa3fc@github.com>
Message-ID: <2V37azOhtW3Q2_qxfo2UlxMrnaB495ZiCDBCtfz-3iw=.d1e328f7-796a-4fa5-83a9-8ab8c0fe8193@github.com>

On Thu, 24 Sep 2020 06:39:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Speaking of JDK-8199735, `cas_set_mark_raw` is also unnecessary now?

Yes, good catch. I found 2 more mark word accessors that I commented on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From shade at openjdk.java.net  Thu Sep 24 06:43:27 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Sep 2020 06:43:27 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <98EEPdiHGZRQuk-pxS17X2y9gE6bWwIKGQ_6cJBdW-Y=.c76cb0e8-e348-4c14-bd46-4e38af680987@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <98EEPdiHGZRQuk-pxS17X2y9gE6bWwIKGQ_6cJBdW-Y=.c76cb0e8-e348-4c14-bd46-4e38af680987@github.com>
Message-ID: <umg3i6VhtZjJxUltTLQDrT9wUGSn3IlL_6eaidyjZzI=.ba450b7e-d600-43ca-a90a-67d041baa3fc@github.com>

On Thu, 24 Sep 2020 06:35:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The incremental
>> webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits
>> since the last revision:
>>  - Remove redundant _raw functions.
>>  - 8251358: Clean up Access configuration after Shenandoah barrier change
>
> Marked as reviewed by shade (Reviewer).

Speaking of JDK-8199735, `cas_set_mark_raw` is also unnecessary now?

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From adityam at openjdk.java.net  Thu Sep 24 07:02:31 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Thu, 24 Sep 2020 07:02:31 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <2V37azOhtW3Q2_qxfo2UlxMrnaB495ZiCDBCtfz-3iw=.d1e328f7-796a-4fa5-83a9-8ab8c0fe8193@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <98EEPdiHGZRQuk-pxS17X2y9gE6bWwIKGQ_6cJBdW-Y=.c76cb0e8-e348-4c14-bd46-4e38af680987@github.com>
 <umg3i6VhtZjJxUltTLQDrT9wUGSn3IlL_6eaidyjZzI=.ba450b7e-d600-43ca-a90a-67d041baa3fc@github.com>
 <2V37azOhtW3Q2_qxfo2UlxMrnaB495ZiCDBCtfz-3iw=.d1e328f7-796a-4fa5-83a9-8ab8c0fe8193@github.com>
Message-ID: <tGMjga5NBZf3uIm17L3mHmX1NNVrSsUAIdOG-dh2oLk=.78feff69-a70e-4e34-af74-bbe22d4381ba@github.com>

On Thu, 24 Sep 2020 06:41:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Speaking of JDK-8199735, `cas_set_mark_raw` is also unnecessary now?
>
>> Speaking of JDK-8199735, `cas_set_mark_raw` is also unnecessary now?
> 
> Yes, good catch. I found 2 more mark word accessors that I commented on.

Thanks @shipilev and @fisk . I had left `cas_set_mark_raw` alone since there's a caller that specifies
`memory_order_release` and I didn't want to change any behavior with the cleanup:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp#L242

That said, I haven't looked into how necessary that is; perhaps it's okay to change it to relaxed order.

@fisk Thanks for taking another look. I don't see the new comments you added yet. Have you submitted them?

I'll follow up on this PR tomorrow since it's quite late here ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From shade at redhat.com  Thu Sep 24 07:06:56 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 24 Sep 2020 09:06:56 +0200
Subject: [11u] RFR (XS) 8253224: Shenandoah: ShenandoahStrDedupQueue
 destructor calls virtual num_queues()
Message-ID: <004e7d93-e6f0-6215-17e6-35b08547ea58@redhat.com>

Original fix:
   https://bugs.openjdk.java.net/browse/JDK-8253224
   https://git.openjdk.java.net/jdk/commit/c781594b

This is the first backport after moving to Git, so the changeset is generated with "git hg-export". 
It also does not apply cleanly, because the context changed a bit.

11u variant:

diff -r dd09e5aaa34e src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp       Fri Aug 24 09:38:11 2018 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp       Thu Sep 24 09:06:32 2020 +0200
@@ -50,5 +50,5 @@
  ShenandoahStrDedupQueue::~ShenandoahStrDedupQueue() {
    MonitorLockerEx ml(StringDedupQueue_lock, Mutex::_no_safepoint_check_flag);
-  for (size_t index = 0; index < num_queues(); index ++) {
+  for (size_t index = 0; index < num_queues_nv(); index ++) {
      release_buffers(queue_at(index));
    }
diff -r dd09e5aaa34e src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp       Fri Aug 24 09:38:11 2018 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp       Thu Sep 24 09:06:32 2020 +0200
@@ -95,7 +95,9 @@

  protected:
-  size_t num_queues() const { return (_num_producer_queue + 2); }
+  size_t num_queues() const { return num_queues_nv(); }

  private:
+  inline size_t num_queues_nv() const { return (_num_producer_queue + 2); }
+
    ShenandoahQueueBuffer* new_buffer();


Testing: hotspot_gc_shenandoah


-- 
Thanks,
-Aleksey


From eosterlund at openjdk.java.net  Thu Sep 24 07:30:31 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Sep 2020 07:30:31 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <yz8pzus3E_xSZOlnmm-vl0evNXkVfzP6qPUJBXTsPT8=.426c880a-3a64-44c1-bd3b-374250f6cf1f@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <yz8pzus3E_xSZOlnmm-vl0evNXkVfzP6qPUJBXTsPT8=.426c880a-3a64-44c1-bd3b-374250f6cf1f@github.com>
Message-ID: <kj4ORhmVU0mttSm08CNtxDKwtzvJu1nDTDBJoY9R0NE=.d0077a3f-2f25-41a4-b71e-548193b075bf@github.com>

On Thu, 24 Sep 2020 07:25:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The incremental
>> webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits
>> since the last revision:
>>  - Remove redundant _raw functions.
>>  - 8251358: Clean up Access configuration after Shenandoah barrier change
>
> Oops seems like I didn't publish the comments somehow.

> Thanks @shipilev and @fisk . I had left `cas_set_mark_raw` alone since there's a caller that specifies
> `memory_order_release` and I didn't want to change any behavior with the cleanup:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp#L242
> 
> That said, I haven't looked into how necessary that is; perhaps it's okay to change it to relaxed order.
> 
> 
> 
> @fisk Thanks for taking another look. I don't see the new comments you added yet. Have you submitted them?
> 
> 
> 
> I'll follow up on this PR tomorrow since it's quite late here ??
> 
> 

A lot of thought has gone into the memory ordering flags. This change should definitely not change any of that. Having
said that, I can't see why we can not rename raw functions to not raw functions, while maintaining the same memory
ordering.

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From eosterlund at openjdk.java.net  Thu Sep 24 07:30:29 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Sep 2020 07:30:29 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
Message-ID: <yz8pzus3E_xSZOlnmm-vl0evNXkVfzP6qPUJBXTsPT8=.426c880a-3a64-44c1-bd3b-374250f6cf1f@github.com>

On Wed, 23 Sep 2020 01:13:08 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
>> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
>> removed, and callers have been modified.  Testing done:
>> tier1
>> hotspot_gc_shenandoah
>
> Aditya Mandaleeka has updated the pull request with a new target base due to a merge or a rebase. The incremental
> webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits
> since the last revision:
>  - Remove redundant _raw functions.
>  - 8251358: Clean up Access configuration after Shenandoah barrier change

Oops seems like I didn't publish the comments somehow.

src/hotspot/share/oops/oop.hpp line 62:

> 60:  public:
> 61:   inline markWord  mark()          const;
> 62:   inline markWord* mark_addr_raw() const;

mark_addr_raw should now be mark_addr.

src/hotspot/share/oops/oop.hpp line 65:

> 63:
> 64:   inline void set_mark(markWord m);
> 65:   static inline void set_mark_raw(HeapWord* mem, markWord m);

set_mark_raw should now be set_mark.

-------------

Changes requested by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/146

From zgu at redhat.com  Thu Sep 24 12:03:21 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 24 Sep 2020 08:03:21 -0400
Subject: [11u] RFR (XS) 8253224: Shenandoah: ShenandoahStrDedupQueue
 destructor calls virtual num_queues()
In-Reply-To: <004e7d93-e6f0-6215-17e6-35b08547ea58@redhat.com>
References: <004e7d93-e6f0-6215-17e6-35b08547ea58@redhat.com>
Message-ID: <fd322131-d48c-ba7f-8cc8-a110e7d60a7c@redhat.com>

Looks good.

Thanks,

-Zhengyu

On 9/24/20 3:06 AM, Aleksey Shipilev wrote:
> Original fix:
>  ? https://bugs.openjdk.java.net/browse/JDK-8253224
>  ? https://git.openjdk.java.net/jdk/commit/c781594b
> 
> This is the first backport after moving to Git, so the changeset is 
> generated with "git hg-export". It also does not apply cleanly, because 
> the context changed a bit.
> 
> 11u variant:
> 
> diff -r dd09e5aaa34e 
> src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp       
> Fri Aug 24 09:38:11 2018 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp       
> Thu Sep 24 09:06:32 2020 +0200
> @@ -50,5 +50,5 @@
>  ?ShenandoahStrDedupQueue::~ShenandoahStrDedupQueue() {
>  ?? MonitorLockerEx ml(StringDedupQueue_lock, 
> Mutex::_no_safepoint_check_flag);
> -? for (size_t index = 0; index < num_queues(); index ++) {
> +? for (size_t index = 0; index < num_queues_nv(); index ++) {
>  ???? release_buffers(queue_at(index));
>  ?? }
> diff -r dd09e5aaa34e 
> src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp       
> Fri Aug 24 09:38:11 2018 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp       
> Thu Sep 24 09:06:32 2020 +0200
> @@ -95,7 +95,9 @@
> 
>  ?protected:
> -? size_t num_queues() const { return (_num_producer_queue + 2); }
> +? size_t num_queues() const { return num_queues_nv(); }
> 
>  ?private:
> +? inline size_t num_queues_nv() const { return (_num_producer_queue + 
> 2); }
> +
>  ?? ShenandoahQueueBuffer* new_buffer();
> 
> 
> Testing: hotspot_gc_shenandoah
> 
> 


From iklam at openjdk.java.net  Thu Sep 24 13:19:43 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 24 Sep 2020 13:19:43 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <YuLb1saqpS3gnn8FJ2UXnjDEHU0qYfFcJImutdcfAa0=.0e035ddb-ef64-41ff-95f3-2845036dab57@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
 <MeZOuoe1unkK3ZYtNhc2ODqvDBYYGUoEOmaHGGosocw=.83d43d8c-d653-48b0-87b1-e996209de3ae@github.com>
 <YuLb1saqpS3gnn8FJ2UXnjDEHU0qYfFcJImutdcfAa0=.0e035ddb-ef64-41ff-95f3-2845036dab57@github.com>
Message-ID: <wpjH_GtImh2OwB1iTk6I8jOdq7qrSq4Ua3nMDSMhsck=.da4a44d9-8caf-4072-9756-4d2cba1cac4a@github.com>

On Tue, 22 Sep 2020 15:45:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be
> > > flagged.
> > 
> > 
> > It turns out we can't restrict it to unsigned types, at least not very easily. For example,
> > CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before
> > calling this, but that seems a little odd. And I don't know how many more there are after
> > changing that one.
> 
> But shouldn't intptr_t be unsigned? I tested with this:

Oops, my mistake. I thought `intptr_t` was `int*`, but it's in fact "Integer type capable of holding a value converted
from a void pointer and then be converted back to that type with a value that compares equal to the original pointer."

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From mbeckwit at openjdk.java.net  Thu Sep 24 14:04:22 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Thu, 24 Sep 2020 14:04:22 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since
the last revision:

 - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
 - cleanup for 8253457: Remove unimplemented register stack functions
 - Merge remote-tracking branch 'upstream/master' into jdk-windows
 - Update orderAccess_windows_aarch64.hpp
   
   changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
 - 8248787: G1: Workaround MSVC bug
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248670: Windows: Exception handling support on AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248660: AArch64: Make _clear_cache and _nop portable
   Summary: __builtin___clear_cache, etc.
   Contributed-by: mbeckwit, luhenry, burban
 - 8248659: AArch64: Extend CPU Feature detection
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248656: Add Windows AArch64 platform support code
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - 8248498: Add build system support for Windows AArch64
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/6cee388c...2b662010

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/4da7b89e..2b662010

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=04-05

  Stats: 1938 lines in 234 files changed: 652 ins; 841 del; 445 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From mbeckwit at openjdk.java.net  Thu Sep 24 15:15:45 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Thu, 24 Sep 2020 15:15:45 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision:

 - os_windows: remove duplicated UMA handling
 - test_safefetch{32,N} works fine on win+aarch64

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/2b662010..68f61d60

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=05-06

  Stats: 22 lines in 2 files changed: 0 ins; 21 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Thu Sep 24 15:15:47 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Thu, 24 Sep 2020 15:15:47 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
In-Reply-To: <vtLrgunrlk5s8YjPw7UVWcLzGYj5f2nUVjozegqW7GA=.b9fedff1-df09-4080-991f-97d32b1a02ce@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <IPIRqfUzHsFb8ugn81EQIFQMuWa5-dUiSIHBsMHdPc4=.e5c97057-326a-4bcb-91d5-bc0498ea5d8b@github.com>
 <vtLrgunrlk5s8YjPw7UVWcLzGYj5f2nUVjozegqW7GA=.b9fedff1-df09-4080-991f-97d32b1a02ce@github.com>
Message-ID: <r7oM1S3Wgyq3_DAlBFBVOUKmJ9C47BI5mlV29KQwgOw=.56842adc-5651-49df-b460-01c893e091ee@github.com>

On Thu, 24 Sep 2020 04:45:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update orderAccess_windows_aarch64.hpp
>>   
>>   changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
>
> src/hotspot/os/windows/os_windows.cpp line 2546:
> 
>> 2544:
>> 2545: #ifdef _M_ARM64
>> 2546:       // Unsafe memory access
> 
> I'm not at all clear why this unsafe memory access handling is for Aarch64 only?

Hum, this was already part of
[JDK-8250810](https://github.com/openjdk/jdk/commit/a4eaf9536c272862b5ec856bf263679be09bddc9) /
[JDK-8248817](https://github.com/openjdk/jdk/commit/257809d7440e87ac595d03b6c9a98d8f457f314c)  (see a couple lines
below in this PR) without the `ifdef` for Aarch64, but I messed up rebasing on top of it. I removed it now, thanks for
catching!

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Thu Sep 24 15:19:13 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Thu, 24 Sep 2020 15:19:13 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
In-Reply-To: <vtLrgunrlk5s8YjPw7UVWcLzGYj5f2nUVjozegqW7GA=.b9fedff1-df09-4080-991f-97d32b1a02ce@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <IPIRqfUzHsFb8ugn81EQIFQMuWa5-dUiSIHBsMHdPc4=.e5c97057-326a-4bcb-91d5-bc0498ea5d8b@github.com>
 <vtLrgunrlk5s8YjPw7UVWcLzGYj5f2nUVjozegqW7GA=.b9fedff1-df09-4080-991f-97d32b1a02ce@github.com>
Message-ID: <A_qKy8T1YvPwc3GajKcjj7jPqDKqoMhRevkYL15UkPY=.11801259-8cf0-43c8-b3f9-7d26382cba85@github.com>

On Thu, 24 Sep 2020 04:52:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update orderAccess_windows_aarch64.hpp
>>   
>>   changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
>
> src/hotspot/share/runtime/stubRoutines.cpp line 397:
> 
>> 395:   // test safefetch routines
>> 396:   // Not on Windows 32bit until 8074860 is fixed
>> 397: #if ! (defined(_WIN32) && defined(_M_IX86)) && !defined(_M_ARM64)
> 
> The comment needs updating to refer to Aarch64.

This is actually not needed anymore, as it does work just fine on Windows+Aarch64. Presumably we have added it in the
early days of the port when we haven't figured out exception handling quite yet.

Thanks for catching David.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From cjplummer at openjdk.java.net  Thu Sep 24 15:47:05 2020
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Sep 2020 15:47:05 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
In-Reply-To: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com>
Message-ID: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com>

On Thu, 24 Sep 2020 14:04:22 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since
> the last revision:
>  - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
>  - cleanup for 8253457: Remove unimplemented register stack functions
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - Update orderAccess_windows_aarch64.hpp
>    
>    changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
>  - 8248787: G1: Workaround MSVC bug
>    Reviewed-by:
>    Contributed-by: mbeckwit, luhenry, burban
>  - 8248670: Windows: Exception handling support on AArch64
>    Reviewed-by:
>    Contributed-by: mbeckwit, luhenry, burban
>  - 8248660: AArch64: Make _clear_cache and _nop portable
>    Summary: __builtin___clear_cache, etc.
>    Contributed-by: mbeckwit, luhenry, burban
>  - 8248659: AArch64: Extend CPU Feature detection
>    Reviewed-by:
>    Contributed-by: mbeckwit, luhenry, burban
>  - 8248656: Add Windows AArch64 platform support code
>    Reviewed-by:
>    Contributed-by: mbeckwit, luhenry, burban
>  - 8248498: Add build system support for Windows AArch64
>    Reviewed-by:
>    Contributed-by: mbeckwit, luhenry, burban
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/ddd43bee...2b662010

I looked at changes to existing SA files. These changes look fine.

I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64
versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know.

As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of
other non-SA files that are new and also have the same copyright issue.

I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs
a copyright date update.

-------------

Changes requested by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/212

From stefank at openjdk.java.net  Thu Sep 24 16:30:29 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 24 Sep 2020 16:30:29 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
Message-ID: <GT8oZBnnXgccqX30SuUN_56YHrLlubyqgIerG78KP6w=.336244b6-5956-458f-a665-ca50e671c512@github.com>

On Tue, 22 Sep 2020 07:08:35 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html
> 
> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL,
> PROT_NONE), the function was made aware of exec permissions.
> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference
> compared with old code.
> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and
> immediately reflects this in diagnostic tools like ps.  For executable regions it would require MAP_FIXED|MAP_JIT, so
> instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently
> this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not
> shrink (if I haven't missed anything, by the implementation and in principle).  Tested:
> * local tier1
> * jdk-submit
> * codesign[2] with hardened runtime and allow-jit but without
> allow-unsigned-executable-memory entitlements[3] produce a working bundle.
> 
> (adding GC group as suggested by @dholmes-ora)
> 
> 
> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227
> [2]
>  
>   codesign \
>     --sign - \
>     --options runtime \
>     --entitlements ents.plist \
>     --timestamp \
>     $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib
> [3]
>   <?xml version="1.0" encoding="UTF-8"?>
>   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>   <plist version="1.0">
>     <dict>
>       <key>com.apple.security.cs.allow-jit</key>
>       <true/>
>       <key>com.apple.security.cs.disable-library-validation</key>
>       <true/>
>       <key>com.apple.security.cs.allow-dyld-environment-variables</key>
>       <true/>
>     </dict>
>   </plist>

I started to look at some of these changes and I have a hunch that we don't ever use MAP_FIXED when reserving memory. I
have a prototype that cleans that out, but I need more time to complete it and pull it through our testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From mbeckwit at openjdk.java.net  Thu Sep 24 22:04:56 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Thu, 24 Sep 2020 22:04:56 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com>
 <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com>
Message-ID: <5ZsmSA9duJz5k77S_uvs3cJWDiQAv9ZkB6Nj1mede14=.27ded45d-7093-4151-ac83-7baf1b5ae3d4@github.com>

On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since
>> the last revision:
>>  - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
>>  - cleanup for 8253457: Remove unimplemented register stack functions
>>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>>  - Update orderAccess_windows_aarch64.hpp
>>    
>>    changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
>>  - 8248787: G1: Workaround MSVC bug
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248670: Windows: Exception handling support on AArch64
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248660: AArch64: Make _clear_cache and _nop portable
>>    Summary: __builtin___clear_cache, etc.
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248659: AArch64: Extend CPU Feature detection
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248656: Add Windows AArch64 platform support code
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248498: Add build system support for Windows AArch64
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/6fea1339...2b662010
>
> I looked at changes to existing SA files. These changes look fine.
> 
> I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64
> versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know.
> As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of
> other non-SA files that are new and also have the same copyright issue.
> I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs
> a copyright date update.

@dholmes-ora, makes sense. I will do the needful. Thanks.

> @mo-beck This PR should not be associated with any JBS issues which are targeted at repo-aarch64-port. All such issues
> should have been closed by now when the associated code was pushed to aarch64-port repo. That was the whole point of
> creating separate issues so that they could be tracked in the porting repo. Now that all of that work should be
> complete the only issue that should remain open in relation to the Windows-Aarch64 port is JDK-8248238. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From github.com+51754783+CoreyAshford at openjdk.java.net  Thu Sep 24 22:52:34 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Thu, 24 Sep 2020 22:52:34 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
Message-ID: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>

This patch set encompasses the following commits:

- Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
  the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
- Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
  implementation
- Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
- Adds a JMH microbenchmark for both Base64 encoding and encoding.
- Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

-------------

Commit messages:
 - Expand the Base64 intrinsic regression test to cover decodeBlock
 - Add JMH benchmark for Base64 variable length buffer decoding
 - Add Power9+ intrinsic implementation for Base64 decoding
 - Add HotSpot code to implement Base64 decodeBlock API
 - Add HotSpotIntrinsicCandidate and API for Base64 decoding

Changes: https://git.openjdk.java.net/jdk/pull/293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248188
  Stats: 1925 lines in 24 files changed: 1899 ins; 4 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+CoreyAshford at openjdk.java.net  Thu Sep 24 22:52:34 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Thu, 24 Sep 2020 22:52:34 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com>

On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

This work is covered by an existing IBM <-> Oracle agreement

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From david.holmes at oracle.com  Fri Sep 25 01:34:10 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 25 Sep 2020 11:34:10 +1000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com>
 <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com>
Message-ID: <14d09119-7802-bc97-7547-626edee9c959@oracle.com>

Hi Chris, Monica,

On 25/09/2020 1:47 am, Chris Plummer wrote:
> As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of
> other non-SA files that are new and also have the same copyright issue.

If a file was created completely from scratch then it should just have 
the Microsoft copyright notice. However, if it was copied from an 
existing file and modified, then the existing file's copyright should be 
included and a Microsoft one added if the changes are significant.

But IANAL. :)

Cheers,
David

> I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs
> a copyright date update.
> 
> -------------
> 
> Changes requested by cjplummer (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/212
> 

From adityam at openjdk.java.net  Fri Sep 25 04:11:09 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Fri, 25 Sep 2020 04:11:09 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v3]
In-Reply-To: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
Message-ID: <u_WO3mHeUSU2zvWK_csNXQCaUQUzM8TiaIyvkBp2Hzg=.9785a2de-cb18-4008-9191-8fd58f405b4e@github.com>

> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
> removed, and callers have been modified.  Testing done:
> tier1
> hotspot_gc_shenandoah

Aditya Mandaleeka has updated the pull request incrementally with one additional commit since the last revision:

  Rename a few more _raw functions.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/146/files
  - new: https://git.openjdk.java.net/jdk/pull/146/files/45d77581..277e7e0d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=146&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=146&range=01-02

  Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/146.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/146/head:pull/146

PR: https://git.openjdk.java.net/jdk/pull/146

From adityam at openjdk.java.net  Fri Sep 25 04:13:16 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Fri, 25 Sep 2020 04:13:16 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <kj4ORhmVU0mttSm08CNtxDKwtzvJu1nDTDBJoY9R0NE=.d0077a3f-2f25-41a4-b71e-548193b075bf@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <yz8pzus3E_xSZOlnmm-vl0evNXkVfzP6qPUJBXTsPT8=.426c880a-3a64-44c1-bd3b-374250f6cf1f@github.com>
 <kj4ORhmVU0mttSm08CNtxDKwtzvJu1nDTDBJoY9R0NE=.d0077a3f-2f25-41a4-b71e-548193b075bf@github.com>
Message-ID: <r96rpX9cIlIKLLsRmeyHy1WbKCMUXotKx8kKH_r_9Ew=.64e2f95b-e7d0-4b69-94f2-0b9e770058e1@github.com>

On Thu, 24 Sep 2020 07:27:17 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Oops seems like I didn't publish the comments somehow.
>
>> Thanks @shipilev and @fisk . I had left `cas_set_mark_raw` alone since there's a caller that specifies
>> `memory_order_release` and I didn't want to change any behavior with the cleanup:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp#L242
>> 
>> That said, I haven't looked into how necessary that is; perhaps it's okay to change it to relaxed order.
>> 
>> 
>> 
>> @fisk Thanks for taking another look. I don't see the new comments you added yet. Have you submitted them?
>> 
>> 
>> 
>> I'll follow up on this PR tomorrow since it's quite late here ??
>> 
>> 
> 
> A lot of thought has gone into the memory ordering flags. This change should definitely not change any of that. Having
> said that, I can't see why we can not rename raw functions to not raw functions, while maintaining the same memory
> ordering.

That makes sense, and I just pushed an update that renames those functions. `cas_set_mark_raw` had a default argument
for the memory order which I've turned into a required argument in order to disambiguate after the rename. The only
caller that was relying on the default argument was in the Shenandoah forwarding code, and I've updated it to pass in
the memory order.

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From mdoerr at openjdk.java.net  Fri Sep 25 10:28:29 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 25 Sep 2020 10:28:29 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com>
Message-ID: <G-vpUiU8yvqYa3uECqLLHy50iFI0dQH2YaMPaNW4cUc=.28e31b6c-8dca-4147-a841-85a23d2e437e@github.com>

On Wed, 23 Sep 2020 22:28:38 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> This work is covered by an existing IBM <-> Oracle agreement

Hi Corey,

thanks for refactoring the Java code such that it matches the intrinsic implementation. That's a better design.

I'm now looking at the PPC64 platform code. The algorithm looks fine.

I can see you're using clrldi to clear the upper bits of the parameters. But seems like it clears one bit too few.
You can also use cmpwi for the boolean one.

I wonder about the loop unrolling. It doesn't look beneficial because the loop body is large.
Did you measure performance gain by this unrolling?
I think for agressive tuning we'd have to apply techniques like modulo scheduling, but that's much more work.
So please only use unrolling as far as a benefit is measurable.

But you may want to align the loop start to help instruction fetch.

We'll test it, but we don't have Power 10. You guys need to cover that.

Best regards,
Martin

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From aph at openjdk.java.net  Fri Sep 25 12:47:47 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 25 Sep 2020 12:47:47 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]
In-Reply-To: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com>
Message-ID: <Pw93XXVvMMvh-dPGMWn2hDsQaZB8N8zr5GoxWG7a-Qc=.57eac20d-4cd3-4644-a8a1-35a210d5da07@github.com>

On Thu, 24 Sep 2020 15:15:45 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - os_windows: remove duplicated UMA handling
>  - test_safefetch{32,N} works fine on win+aarch64

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From rriggs at openjdk.java.net  Fri Sep 25 14:20:13 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Sep 2020 14:20:13 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com>

On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

Changes requested by rriggs (Reviewer).

src/java.base/share/classes/java/util/Base64.java line 747:

> 745:          * Decodes base64 characters, and returns the number of data bytes
> 746:          * produced by the base64 decode intrinsic.
> 747:          *

"intrinsic" can be omitted. Both the java and the intrinsic produce the same output.

src/java.base/share/classes/java/util/Base64.java line 759:

> 757:          * src, it must process a multiple of four of them, making the
> 758:          * returned destination length a multiple of three.
> 759:          *

If the dst array is too short does the intrinsic stop short or throw?
The java code would throw an ArrayIndexOutOfBoundsException.
It should not occur since the java code allocates the proper buffer but...
It might be worth mentioning.

src/java.base/share/classes/java/util/Base64.java line 820:

> 818:                     dp += dl;
> 819:                 }
> 820:                 if (sp == sl) {

I'd rather see  (sp >= s1) instead of the equality, its would be consistent with the condition of the while loop.
(And is already lines 767-768).

test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 260:

> 258:     }
> 259:
> 260:     private static final byte[] nonBase64 = {

Please add a comment describing this test data.
(It looks like it could be generated more compactly than an explicit array).
Ditto nonBase64URL below.

test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 240:

> 238:     }
> 239:
> 240:     private static byte[] hexStringToByteArray(String s) {

A method to convert a Hex String to a byte array already exists in test/lib/jdk/test/lib/Utils.java  in  toByteArray(s).
Add "jdk.test.lib.Utils" to the "@build" line at the top of the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From mdoerr at openjdk.java.net  Sat Sep 26 15:36:28 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Sat, 26 Sep 2020 15:36:28 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>

On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

AOT support needs an update:
#  Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316
#  guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock

V  [jvm.dll+0x1dbc6e]  AOTCodeHeap::link_stub_routines_symbols+0xf7e  (aotcodeheap.cpp:557)
V  [jvm.dll+0x1d95e8]  AOTCodeHeap::link_global_lib_symbols+0x2f8  (aotcodeheap.cpp:603)
V  [jvm.dll+0x1dc616]  AOTCodeHeap::load_klass_data+0x476  (aotcodeheap.cpp:840)
V  [jvm.dll+0x1e1021]  AOTLoader::load_for_klass+0x161  (aotloader.cpp:55)
V  [jvm.dll+0x5fec96]  InstanceKlass::initialize_impl+0x4e6  (instanceklass.cpp:1159)
V  [jvm.dll+0x5fead6]  InstanceKlass::initialize_impl+0x326  (instanceklass.cpp:1133)
V  [jvm.dll+0xc5a633]  Threads::initialize_java_lang_classes+0x93  (thread.cpp:3766)
V  [jvm.dll+0xc57c32]  Threads::create_vm+0xa12  (thread.cpp:4037)

Can be reproduced by running JTREG tests:
compiler/aot/calls/fromAot

-------------

Changes requested by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/293

From shade at redhat.com  Mon Sep 28 07:48:52 2020
From: shade at redhat.com (shade at redhat.com)
Date: Mon, 28 Sep 2020 07:48:52 +0000
Subject: hg: shenandoah/jdk8/corba: 12 new changesets
Message-ID: <202009280748.08S7mqj5009079@aojmv0008.oracle.com>

Changeset: 5fdee3224c7d
Author:    valeriep
Date:      2020-05-11 18:49 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/5fdee3224c7d

8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26
Summary: Updated from 1.8.24 to 1.8.26
Reviewed-by: xuelei

! THIRD_PARTY_README

Changeset: 5f9992e13e8e
Author:    andrew
Date:      2020-08-28 07:33 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/5f9992e13e8e

Merge


Changeset: f4d4a3f880da
Author:    mbalao
Date:      2020-08-27 21:00 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/f4d4a3f880da

8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
Summary: Added support for GCM, PSS, and other mechanisms
Reviewed-by: andrew

! THIRD_PARTY_README

Changeset: 2d2435272ddd
Author:    andrew
Date:      2020-08-31 07:09 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2d2435272ddd

Added tag jdk8u272-b06 for changeset f4d4a3f880da

! .hgtags

Changeset: e806d8c0c56f
Author:    andrew
Date:      2020-09-03 06:16 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e806d8c0c56f

Merge jdk8u272-b06

! .hgtags
! THIRD_PARTY_README

Changeset: 1343c386d59d
Author:    andrew
Date:      2020-09-03 06:17 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/1343c386d59d

Added tag aarch64-shenandoah-jdk8u272-b06 for changeset e806d8c0c56f

! .hgtags

Changeset: d652c48a90eb
Author:    andrew
Date:      2020-09-07 06:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/d652c48a90eb

Added tag jdk8u272-b07 for changeset 2d2435272ddd

! .hgtags

Changeset: 57130d380945
Author:    andrew
Date:      2020-09-08 13:39 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/57130d380945

Merge jdk8u272-b07

! .hgtags

Changeset: 32f38793133f
Author:    andrew
Date:      2020-09-08 13:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/32f38793133f

Added tag aarch64-shenandoah-jdk8u272-b07 for changeset 57130d380945

! .hgtags

Changeset: 244b07da2440
Author:    andrew
Date:      2020-09-14 16:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/244b07da2440

Added tag jdk8u272-b08 for changeset d652c48a90eb

! .hgtags

Changeset: 20fe18599380
Author:    andrew
Date:      2020-09-16 03:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/20fe18599380

Merge jdk8u272-b08

! .hgtags

Changeset: ec336c03d7a9
Author:    andrew
Date:      2020-09-16 03:34 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/ec336c03d7a9

Added tag aarch64-shenandoah-jdk8u272-b08 for changeset 20fe18599380

! .hgtags


From shade at redhat.com  Mon Sep 28 07:48:53 2020
From: shade at redhat.com (shade at redhat.com)
Date: Mon, 28 Sep 2020 07:48:53 +0000
Subject: hg: shenandoah/jdk8/jaxp: 12 new changesets
Message-ID: <202009280748.08S7mrEN009152@aojmv0008.oracle.com>

Changeset: 8e1df6da422c
Author:    valeriep
Date:      2020-05-11 18:49 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/8e1df6da422c

8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26
Summary: Updated from 1.8.24 to 1.8.26
Reviewed-by: xuelei

! THIRD_PARTY_README

Changeset: df8890249d97
Author:    andrew
Date:      2020-08-28 07:33 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/df8890249d97

Merge


Changeset: 44cbebcc276c
Author:    mbalao
Date:      2020-08-27 21:00 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/44cbebcc276c

8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
Summary: Added support for GCM, PSS, and other mechanisms
Reviewed-by: andrew

! THIRD_PARTY_README

Changeset: bd015816ce49
Author:    andrew
Date:      2020-08-31 07:09 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/bd015816ce49

Added tag jdk8u272-b06 for changeset 44cbebcc276c

! .hgtags

Changeset: 1bffaa2f576d
Author:    andrew
Date:      2020-09-03 06:16 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/1bffaa2f576d

Merge jdk8u272-b06

! .hgtags
! THIRD_PARTY_README

Changeset: 73054a6085e6
Author:    andrew
Date:      2020-09-03 06:17 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/73054a6085e6

Added tag aarch64-shenandoah-jdk8u272-b06 for changeset 1bffaa2f576d

! .hgtags

Changeset: 9d92962b2fe3
Author:    andrew
Date:      2020-09-07 06:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/9d92962b2fe3

Added tag jdk8u272-b07 for changeset bd015816ce49

! .hgtags

Changeset: 86d1340582fe
Author:    andrew
Date:      2020-09-08 13:39 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/86d1340582fe

Merge jdk8u272-b07

! .hgtags

Changeset: 00c204404ae3
Author:    andrew
Date:      2020-09-08 13:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/00c204404ae3

Added tag aarch64-shenandoah-jdk8u272-b07 for changeset 86d1340582fe

! .hgtags

Changeset: a5b79eebcc1f
Author:    andrew
Date:      2020-09-14 16:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/a5b79eebcc1f

Added tag jdk8u272-b08 for changeset 9d92962b2fe3

! .hgtags

Changeset: 81702d085f64
Author:    andrew
Date:      2020-09-16 03:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/81702d085f64

Merge jdk8u272-b08

! .hgtags

Changeset: b55c3fde71b7
Author:    andrew
Date:      2020-09-16 03:34 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/b55c3fde71b7

Added tag aarch64-shenandoah-jdk8u272-b08 for changeset 81702d085f64

! .hgtags


From shade at redhat.com  Mon Sep 28 07:48:55 2020
From: shade at redhat.com (shade at redhat.com)
Date: Mon, 28 Sep 2020 07:48:55 +0000
Subject: hg: shenandoah/jdk8/langtools: 13 new changesets
Message-ID: <202009280748.08S7mt9S009293@aojmv0008.oracle.com>

Changeset: ba4fc0bc6e69
Author:    valeriep
Date:      2020-05-11 18:49 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ba4fc0bc6e69

8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26
Summary: Updated from 1.8.24 to 1.8.26
Reviewed-by: xuelei

! THIRD_PARTY_README

Changeset: bbe3dcbc07e6
Author:    andrew
Date:      2020-08-28 07:33 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/bbe3dcbc07e6

Merge


Changeset: 571945b07fd4
Author:    mbalao
Date:      2020-08-27 21:00 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/571945b07fd4

8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
Summary: Added support for GCM, PSS, and other mechanisms
Reviewed-by: andrew

! THIRD_PARTY_README

Changeset: b974f43a589f
Author:    zgu
Date:      2020-08-29 08:30 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/b974f43a589f

8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider
Reviewed-by: alanb, dfuchs, chegar, mchung, vtewari

! src/share/classes/com/sun/tools/javac/resources/legacy.properties
! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java

Changeset: a56fbe019ae8
Author:    andrew
Date:      2020-08-31 07:09 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a56fbe019ae8

Added tag jdk8u272-b06 for changeset b974f43a589f

! .hgtags

Changeset: 54a3a6d155c4
Author:    andrew
Date:      2020-09-03 06:16 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/54a3a6d155c4

Merge jdk8u272-b06

! .hgtags
! THIRD_PARTY_README

Changeset: d1e0d76fa53e
Author:    andrew
Date:      2020-09-03 06:17 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/d1e0d76fa53e

Added tag aarch64-shenandoah-jdk8u272-b06 for changeset 54a3a6d155c4

! .hgtags

Changeset: 462446582ece
Author:    andrew
Date:      2020-09-07 06:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/462446582ece

Added tag jdk8u272-b07 for changeset a56fbe019ae8

! .hgtags

Changeset: 4d459f9351b9
Author:    andrew
Date:      2020-09-08 13:39 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/4d459f9351b9

Merge jdk8u272-b07

! .hgtags

Changeset: b7c7fca5b4b9
Author:    andrew
Date:      2020-09-08 13:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/b7c7fca5b4b9

Added tag aarch64-shenandoah-jdk8u272-b07 for changeset 4d459f9351b9

! .hgtags

Changeset: acab1eb3dc4c
Author:    andrew
Date:      2020-09-14 16:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/acab1eb3dc4c

Added tag jdk8u272-b08 for changeset 462446582ece

! .hgtags

Changeset: 924ffebbf3e9
Author:    andrew
Date:      2020-09-16 03:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/924ffebbf3e9

Merge jdk8u272-b08

! .hgtags

Changeset: a53e0a7f8b2a
Author:    andrew
Date:      2020-09-16 03:34 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a53e0a7f8b2a

Added tag aarch64-shenandoah-jdk8u272-b08 for changeset 924ffebbf3e9

! .hgtags


From ngasson at openjdk.java.net  Mon Sep 28 07:58:27 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 28 Sep 2020 07:58:27 GMT
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent [v2]
In-Reply-To: <HTaGo6SkguPaB-S4Cam_tjKALpmzsAgbpqi28LxjUP0=.ff8361a9-425d-4a17-acda-fd09ede33056@github.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
 <HTaGo6SkguPaB-S4Cam_tjKALpmzsAgbpqi28LxjUP0=.ff8361a9-425d-4a17-acda-fd09ede33056@github.com>
Message-ID: <Ul1H6TL4qODxrOedhf4wFz_Y6cOh0dd-M6BtT5_6cFI=.a6f70c16-d555-47a2-b278-d9b8028ff962@github.com>

On Mon, 21 Sep 2020 09:49:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only insert trailing barrier when is_c1_or_interpreter_only()
>
> Looks good to me. @shipilev should look at it, too.

Any more comments on the latest version?

-------------

PR: https://git.openjdk.java.net/jdk/pull/280

From shade at redhat.com  Mon Sep 28 07:49:15 2020
From: shade at redhat.com (shade at redhat.com)
Date: Mon, 28 Sep 2020 07:49:15 +0000
Subject: hg: shenandoah/jdk8/jdk: 43 new changesets
Message-ID: <202009280749.08S7nH7I009399@aojmv0008.oracle.com>

Changeset: 61638f2cadb9
Author:    valeriep
Date:      2020-05-11 18:49 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/61638f2cadb9

8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26
Summary: Updated from 1.8.24 to 1.8.26
Reviewed-by: xuelei

! THIRD_PARTY_README
! src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h

Changeset: 4c96e2f298dc
Author:    andrew
Date:      2020-08-26 03:54 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4c96e2f298dc

8144539: Update PKCS11 tests to run with security manager
Reviewed-by: mbalao

! test/sun/security/pkcs11/Cipher/ReinitCipher.java
! test/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java
! test/sun/security/pkcs11/Cipher/TestRSACipher.java
! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java
! test/sun/security/pkcs11/Cipher/TestRawRSACipher.java
! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java
! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java
! test/sun/security/pkcs11/KeyAgreement/TestDH.java
! test/sun/security/pkcs11/KeyAgreement/TestInterop.java
! test/sun/security/pkcs11/KeyAgreement/TestShort.java
! test/sun/security/pkcs11/KeyGenerator/DESParity.java
! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java
! test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java
! test/sun/security/pkcs11/Mac/MacKAT.java
! test/sun/security/pkcs11/Mac/MacSameTest.java
! test/sun/security/pkcs11/Mac/ReinitMac.java
! test/sun/security/pkcs11/MessageDigest/ByteBuffers.java
! test/sun/security/pkcs11/MessageDigest/DigestKAT.java
! test/sun/security/pkcs11/MessageDigest/ReinitDigest.java
! test/sun/security/pkcs11/MessageDigest/TestCloning.java
! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/Secmod/AddPrivateKey.java
! test/sun/security/pkcs11/Secmod/AddTrustedCert.java
! test/sun/security/pkcs11/Secmod/Crypto.java
! test/sun/security/pkcs11/Secmod/GetPrivateKey.java
! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java
! test/sun/security/pkcs11/Secmod/LoadKeystore.java
! test/sun/security/pkcs11/Secmod/TrustAnchors.java
+ test/sun/security/pkcs11/Secmod/policy
! test/sun/security/pkcs11/SecureRandom/Basic.java
! test/sun/security/pkcs11/Signature/ByteBuffers.java
! test/sun/security/pkcs11/Signature/TestDSA.java
! test/sun/security/pkcs11/Signature/TestDSAKeyLength.java
! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/ReadPKCS12.java
! test/sun/security/pkcs11/ec/TestCurves.java
! test/sun/security/pkcs11/ec/TestECDH.java
! test/sun/security/pkcs11/ec/TestECDH2.java
! test/sun/security/pkcs11/ec/TestECDSA.java
! test/sun/security/pkcs11/ec/TestECDSA2.java
! test/sun/security/pkcs11/ec/TestECGenSpec.java
! test/sun/security/pkcs11/ec/TestKeyFactory.java
+ test/sun/security/pkcs11/ec/policy
! test/sun/security/pkcs11/fips/TrustManagerTest.java
+ test/sun/security/pkcs11/fips/TrustManagerTest.policy
+ test/sun/security/pkcs11/policy
! test/sun/security/pkcs11/rsa/KeyWrap.java
! test/sun/security/pkcs11/rsa/TestCACerts.java
+ test/sun/security/pkcs11/rsa/TestCACerts.policy
! test/sun/security/pkcs11/rsa/TestKeyFactory.java
! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java
+ test/sun/security/pkcs11/rsa/TestKeyPairGenerator.policy
! test/sun/security/pkcs11/rsa/TestSignatures.java
+ test/sun/security/pkcs11/rsa/rsakeys.ks.policy
! test/sun/security/pkcs11/sslecc/CipherTest.java
+ test/sun/security/pkcs11/sslecc/policy
! test/sun/security/pkcs11/tls/TestKeyMaterial.java
! test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java
! test/sun/security/pkcs11/tls/TestMasterSecret.java
+ test/sun/security/pkcs11/tls/TestMasterSecret.policy
! test/sun/security/pkcs11/tls/TestPRF.java
! test/sun/security/pkcs11/tls/TestPremaster.java
+ test/sun/security/pkcs11/tls/policy

Changeset: f88390a07754
Author:    andrew
Date:      2020-08-27 06:13 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f88390a07754

Merge


Changeset: 26c1140d2613
Author:    sgehwolf
Date:      2020-07-03 15:09 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/26c1140d2613

8226575: OperatingSystemMXBean should be made container aware
Reviewed-by: andrew

! make/mapfiles/libmanagement/mapfile-vers
! src/aix/native/sun/management/AixOperatingSystem.c
! src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java
! src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
! src/share/classes/com/sun/management/OperatingSystemMXBean.java
! src/solaris/classes/sun/management/OperatingSystemImpl.java
! src/solaris/native/sun/management/LinuxOperatingSystem.c
! src/solaris/native/sun/management/MacosxOperatingSystem.c
! src/solaris/native/sun/management/OperatingSystemImpl.c
! src/solaris/native/sun/management/SolarisOperatingSystem.c

Changeset: b52035c5f3fa
Author:    mseledtsov
Date:      2019-03-08 11:08 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b52035c5f3fa

8220313: [TESTBUG] Update base image for Docker testing to OL 7.6
Summary: Updated the OL version in Dockerfile in FROM field
Reviewed-by: dcubed

! test/jdk/internal/platform/docker/Dockerfile-BasicTest

Changeset: 060a9636fe44
Author:    andrew
Date:      2020-08-28 07:33 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/060a9636fe44

Merge


Changeset: ef41e0d32c15
Author:    darcy
Date:      2019-06-28 18:51 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ef41e0d32c15

8226809: Circular reference in printed stack trace is not correctly indented & ambiguous
Reviewed-by: bpb

! src/share/classes/java/lang/Throwable.java

Changeset: 47092994d86b
Author:    rhalade
Date:      2020-08-03 11:35 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/47092994d86b

8243320: Add SSL root certificates to Oracle Root CA program
Reviewed-by: mullan

+ make/data/cacerts/sslrooteccca
+ make/data/cacerts/sslrootevrsaca
+ make/data/cacerts/sslrootrsaca
+ test/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java
! test/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: 2dd87e7b528f
Author:    valeriep
Date:      2020-02-28 15:09 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2dd87e7b528f

8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
8169925: PKCS #11 Cryptographic Token Interface license
8238898: Missing hash characters for header on license file
Summary: Added support for GCM, PSS, and other mechanisms
Reviewed-by: jnimeh, phh, andrew

! THIRD_PARTY_README
! make/mapfiles/libj2pkcs11/mapfile-vers
+ src/share/classes/sun/security/pkcs11/P11AEADCipher.java
+ src/share/classes/sun/security/pkcs11/P11PSSSignature.java
! src/share/classes/sun/security/pkcs11/P11RSACipher.java
! src/share/classes/sun/security/pkcs11/SunPKCS11.java
+ src/share/classes/sun/security/pkcs11/wrapper/CK_CCM_PARAMS.java
+ src/share/classes/sun/security/pkcs11/wrapper/CK_GCM_PARAMS.java
! src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java
! src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java
! src/share/classes/sun/security/pkcs11/wrapper/Functions.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java
+ src/share/classes/sun/security/util/GCMParameters.java
! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c
! src/share/native/sun/security/pkcs11/wrapper/p11_general.c
! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
- src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h
! src/share/native/sun/security/pkcs11/wrapper/pkcs11.h
! src/share/native/sun/security/pkcs11/wrapper/pkcs11f.h
! src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h
! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
+ test/sun/security/pkcs11/Cipher/Test4512704.java
+ test/sun/security/pkcs11/Cipher/TestCICOWithGCM.java
+ test/sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java
+ test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java
+ test/sun/security/pkcs11/Cipher/TestKATForGCM.java
! test/sun/security/pkcs11/MessageDigest/ByteBuffers.java
+ test/sun/security/pkcs11/Signature/InitAgainPSS.java
+ test/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
+ test/sun/security/pkcs11/Signature/SigInteropPSS.java
+ test/sun/security/pkcs11/Signature/SignatureTestPSS.java
+ test/sun/security/pkcs11/Signature/TestDSA2.java

Changeset: 58fad4aebb4c
Author:    shade
Date:      2019-06-14 10:02 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/58fad4aebb4c

8225695: 32-bit build failures after JDK-8080462 (Update SunPKCS11 provider with PKCS11 v2.40 support)
Reviewed-by: alanb

! src/share/native/sun/security/pkcs11/wrapper/p11_general.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c

Changeset: d6cec711198e
Author:    weijun
Date:      2017-12-13 01:29 +0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d6cec711198e

8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite
Reviewed-by: weijun, andrew
Contributed-by: Martin Balao <mbalao at redhat.com>

! src/share/classes/sun/security/pkcs11/Secmod.java
+ test/sun/security/pkcs11/Secmod/README-SQLITE
+ test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java
+ test/sun/security/pkcs11/Secmod/cert9.db
+ test/sun/security/pkcs11/Secmod/key4.db
+ test/sun/security/pkcs11/Secmod/nss-sqlite.cfg
! test/sun/security/pkcs11/SecmodTest.java

Changeset: 5f94741b3fc7
Author:    mbalao
Date:      2020-08-04 17:19 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/5f94741b3fc7

8251117: Cannot check P11Key size in P11Cipher and P11AEADCipher
Reviewed-by: valeriep
Contributed-by: zzambers at redhat.com

! src/share/classes/sun/security/pkcs11/P11AEADCipher.java
! src/share/classes/sun/security/pkcs11/P11Cipher.java

Changeset: 7aaaf8998988
Author:    robm
Date:      2018-11-12 08:33 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7aaaf8998988

8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider
Reviewed-by: alanb, dfuchs, chegar, mchung, vtewari

+ src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java
! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java
+ src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java
! src/share/classes/com/sun/jndi/ldap/ServiceLocator.java
+ src/share/classes/com/sun/jndi/ldap/spi/LdapDnsProvider.java
+ src/share/classes/com/sun/jndi/ldap/spi/LdapDnsProviderResult.java
+ test/com/sun/jndi/ldap/LdapDnsProviderTest.java
+ test/com/sun/jndi/ldap/dnsprovider/TestDnsProvider.java
! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.policy

Changeset: 7747b41df314
Author:    valeriep
Date:      2019-08-14 01:40 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7747b41df314

8228835: Memory leak in PKCS11 provider when using AES GCM
Summary: updated freeCKMechanismPtr to free mechanism-specific memories
Reviewed-by: jnimeh, andrew

! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h

Changeset: 17ce8aaff4bd
Author:    abakhtin
Date:      2020-05-20 17:28 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/17ce8aaff4bd

8245467: Remove 8u TLSv1.2 implementation files
Reviewed-by: mbalao

- src/share/classes/sun/security/ssl/ALPNExtension.java
- src/share/classes/sun/security/ssl/Alerts.java
- src/share/classes/sun/security/ssl/AppInputStream.java
- src/share/classes/sun/security/ssl/AppOutputStream.java
- src/share/classes/sun/security/ssl/Authenticator.java
- src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java
- src/share/classes/sun/security/ssl/ByteBufferInputStream.java
- src/share/classes/sun/security/ssl/CipherBox.java
- src/share/classes/sun/security/ssl/CipherSuite.java
- src/share/classes/sun/security/ssl/CipherSuiteList.java
- src/share/classes/sun/security/ssl/ClientHandshaker.java
- src/share/classes/sun/security/ssl/DHClientKeyExchange.java
- src/share/classes/sun/security/ssl/DHCrypt.java
- src/share/classes/sun/security/ssl/Debug.java
- src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
- src/share/classes/sun/security/ssl/ECDHCrypt.java
- src/share/classes/sun/security/ssl/EllipticCurvesExtension.java
- src/share/classes/sun/security/ssl/EllipticPointFormatsExtension.java
- src/share/classes/sun/security/ssl/EngineArgs.java
- src/share/classes/sun/security/ssl/EngineInputRecord.java
- src/share/classes/sun/security/ssl/EngineOutputRecord.java
- src/share/classes/sun/security/ssl/EngineWriter.java
- src/share/classes/sun/security/ssl/EphemeralKeyManager.java
- src/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java
- src/share/classes/sun/security/ssl/ExtensionType.java
- src/share/classes/sun/security/ssl/HandshakeHash.java
- src/share/classes/sun/security/ssl/HandshakeInStream.java
- src/share/classes/sun/security/ssl/HandshakeMessage.java
- src/share/classes/sun/security/ssl/HandshakeOutStream.java
- src/share/classes/sun/security/ssl/HandshakeStateManager.java
- src/share/classes/sun/security/ssl/Handshaker.java
- src/share/classes/sun/security/ssl/HelloExtension.java
- src/share/classes/sun/security/ssl/HelloExtensions.java
- src/share/classes/sun/security/ssl/InputRecord.java
- src/share/classes/sun/security/ssl/JsseJce.java
- src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
- src/share/classes/sun/security/ssl/MAC.java
- src/share/classes/sun/security/ssl/OutputRecord.java
- src/share/classes/sun/security/ssl/ProtocolList.java
- src/share/classes/sun/security/ssl/ProtocolVersion.java
- src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
- src/share/classes/sun/security/ssl/RSASignature.java
- src/share/classes/sun/security/ssl/RandomCookie.java
- src/share/classes/sun/security/ssl/Record.java
- src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java
- src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
- src/share/classes/sun/security/ssl/SSLAlgorithmDecomposer.java
- src/share/classes/sun/security/ssl/SSLContextImpl.java
- src/share/classes/sun/security/ssl/SSLEngineImpl.java
- src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java
- src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
- src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
- src/share/classes/sun/security/ssl/SSLSessionImpl.java
- src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java
- src/share/classes/sun/security/ssl/SSLSocketImpl.java
- src/share/classes/sun/security/ssl/ServerHandshaker.java
- src/share/classes/sun/security/ssl/ServerNameExtension.java
- src/share/classes/sun/security/ssl/SessionId.java
- src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
- src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
- src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
- src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
- src/share/classes/sun/security/ssl/TrustStoreManager.java
- src/share/classes/sun/security/ssl/UnknownExtension.java
- src/share/classes/sun/security/ssl/Utilities.java
- src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
- src/share/classes/sun/security/ssl/X509TrustManagerImpl.java

Changeset: d0b56fcd1708
Author:    abakhtin
Date:      2020-08-25 08:31 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d0b56fcd1708

8245468: Add TLSv1.3 implementation classes from 11.0.7
Reviewed-by: mbalao

+ src/share/classes/sun/security/ssl/Alert.java
+ src/share/classes/sun/security/ssl/AlpnExtension.java
+ src/share/classes/sun/security/ssl/Authenticator.java
+ src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java
+ src/share/classes/sun/security/ssl/CertSignAlgsExtension.java
+ src/share/classes/sun/security/ssl/CertStatusExtension.java
+ src/share/classes/sun/security/ssl/CertificateMessage.java
+ src/share/classes/sun/security/ssl/CertificateRequest.java
+ src/share/classes/sun/security/ssl/CertificateStatus.java
+ src/share/classes/sun/security/ssl/CertificateVerify.java
+ src/share/classes/sun/security/ssl/ChangeCipherSpec.java
+ src/share/classes/sun/security/ssl/CipherSuite.java
+ src/share/classes/sun/security/ssl/CipherType.java
+ src/share/classes/sun/security/ssl/Ciphertext.java
+ src/share/classes/sun/security/ssl/ClientAuthType.java
+ src/share/classes/sun/security/ssl/ClientHandshakeContext.java
+ src/share/classes/sun/security/ssl/ClientHello.java
+ src/share/classes/sun/security/ssl/ClientKeyExchange.java
+ src/share/classes/sun/security/ssl/ConnectionContext.java
+ src/share/classes/sun/security/ssl/ContentType.java
+ src/share/classes/sun/security/ssl/CookieExtension.java
+ src/share/classes/sun/security/ssl/DHClientKeyExchange.java
+ src/share/classes/sun/security/ssl/DHKeyExchange.java
+ src/share/classes/sun/security/ssl/DHServerKeyExchange.java
+ src/share/classes/sun/security/ssl/DTLSInputRecord.java
+ src/share/classes/sun/security/ssl/DTLSOutputRecord.java
+ src/share/classes/sun/security/ssl/DTLSRecord.java
+ src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
+ src/share/classes/sun/security/ssl/ECDHKeyExchange.java
+ src/share/classes/sun/security/ssl/ECDHServerKeyExchange.java
+ src/share/classes/sun/security/ssl/ECPointFormatsExtension.java
+ src/share/classes/sun/security/ssl/EncryptedExtensions.java
+ src/share/classes/sun/security/ssl/EphemeralKeyManager.java
+ src/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java
+ src/share/classes/sun/security/ssl/Finished.java
+ src/share/classes/sun/security/ssl/HKDF.java
+ src/share/classes/sun/security/ssl/HandshakeAbsence.java
+ src/share/classes/sun/security/ssl/HandshakeConsumer.java
+ src/share/classes/sun/security/ssl/HandshakeContext.java
+ src/share/classes/sun/security/ssl/HandshakeHash.java
+ src/share/classes/sun/security/ssl/HandshakeOutStream.java
+ src/share/classes/sun/security/ssl/HandshakeProducer.java
+ src/share/classes/sun/security/ssl/HelloCookieManager.java
+ src/share/classes/sun/security/ssl/HelloRequest.java
+ src/share/classes/sun/security/ssl/HelloVerifyRequest.java
+ src/share/classes/sun/security/ssl/InputRecord.java
+ src/share/classes/sun/security/ssl/JsseJce.java
+ src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
+ src/share/classes/sun/security/ssl/KeyShareExtension.java
+ src/share/classes/sun/security/ssl/KeyUpdate.java
+ src/share/classes/sun/security/ssl/MaxFragExtension.java
+ src/share/classes/sun/security/ssl/NewSessionTicket.java
+ src/share/classes/sun/security/ssl/OutputRecord.java
+ src/share/classes/sun/security/ssl/Plaintext.java
+ src/share/classes/sun/security/ssl/PostHandshakeContext.java
+ src/share/classes/sun/security/ssl/PreSharedKeyExtension.java
+ src/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java
+ src/share/classes/sun/security/ssl/ProtocolVersion.java
+ src/share/classes/sun/security/ssl/PskKeyExchangeModesExtension.java
+ src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
+ src/share/classes/sun/security/ssl/RSAKeyExchange.java
+ src/share/classes/sun/security/ssl/RSAServerKeyExchange.java
+ src/share/classes/sun/security/ssl/RSASignature.java
+ src/share/classes/sun/security/ssl/RandomCookie.java
+ src/share/classes/sun/security/ssl/Record.java
+ src/share/classes/sun/security/ssl/RenegoInfoExtension.java
+ src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
+ src/share/classes/sun/security/ssl/SSLAlgorithmDecomposer.java
+ src/share/classes/sun/security/ssl/SSLAuthentication.java
+ src/share/classes/sun/security/ssl/SSLBasicKeyDerivation.java
+ src/share/classes/sun/security/ssl/SSLCipher.java
+ src/share/classes/sun/security/ssl/SSLConfiguration.java
+ src/share/classes/sun/security/ssl/SSLConsumer.java
+ src/share/classes/sun/security/ssl/SSLContextImpl.java
+ src/share/classes/sun/security/ssl/SSLCredentials.java
+ src/share/classes/sun/security/ssl/SSLEngineImpl.java
+ src/share/classes/sun/security/ssl/SSLEngineInputRecord.java
+ src/share/classes/sun/security/ssl/SSLEngineOutputRecord.java
+ src/share/classes/sun/security/ssl/SSLExtension.java
+ src/share/classes/sun/security/ssl/SSLExtensions.java
+ src/share/classes/sun/security/ssl/SSLHandshake.java
+ src/share/classes/sun/security/ssl/SSLHandshakeBinding.java
+ src/share/classes/sun/security/ssl/SSLKeyAgreement.java
+ src/share/classes/sun/security/ssl/SSLKeyAgreementGenerator.java
+ src/share/classes/sun/security/ssl/SSLKeyDerivation.java
+ src/share/classes/sun/security/ssl/SSLKeyDerivationGenerator.java
+ src/share/classes/sun/security/ssl/SSLKeyExchange.java
+ src/share/classes/sun/security/ssl/SSLLogger.java
+ src/share/classes/sun/security/ssl/SSLMasterKeyDerivation.java
+ src/share/classes/sun/security/ssl/SSLPossession.java
+ src/share/classes/sun/security/ssl/SSLPossessionGenerator.java
+ src/share/classes/sun/security/ssl/SSLProducer.java
+ src/share/classes/sun/security/ssl/SSLRecord.java
+ src/share/classes/sun/security/ssl/SSLSecretDerivation.java
+ src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java
+ src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
+ src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
+ src/share/classes/sun/security/ssl/SSLSessionImpl.java
+ src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java
+ src/share/classes/sun/security/ssl/SSLSocketImpl.java
+ src/share/classes/sun/security/ssl/SSLSocketInputRecord.java
+ src/share/classes/sun/security/ssl/SSLSocketOutputRecord.java
+ src/share/classes/sun/security/ssl/SSLStringizer.java
+ src/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java
+ src/share/classes/sun/security/ssl/SSLTransport.java
+ src/share/classes/sun/security/ssl/ServerHandshakeContext.java
+ src/share/classes/sun/security/ssl/ServerHello.java
+ src/share/classes/sun/security/ssl/ServerHelloDone.java
+ src/share/classes/sun/security/ssl/ServerKeyExchange.java
+ src/share/classes/sun/security/ssl/ServerNameExtension.java
+ src/share/classes/sun/security/ssl/SessionId.java
+ src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
+ src/share/classes/sun/security/ssl/SignatureScheme.java
+ src/share/classes/sun/security/ssl/StatusResponseManager.java
! src/share/classes/sun/security/ssl/SunJSSE.java
+ src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
+ src/share/classes/sun/security/ssl/SupportedGroupsExtension.java
+ src/share/classes/sun/security/ssl/SupportedVersionsExtension.java
+ src/share/classes/sun/security/ssl/TransportContext.java
+ src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
+ src/share/classes/sun/security/ssl/TrustStoreManager.java
+ src/share/classes/sun/security/ssl/Utilities.java
+ src/share/classes/sun/security/ssl/X509Authentication.java
+ src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
+ src/share/classes/sun/security/ssl/X509TrustManagerImpl.java
! src/share/lib/security/java.security-aix
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 646e29e5330b
Author:    abakhtin
Date:      2020-08-25 08:35 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/646e29e5330b

8245469: Remove DTLS protocol implementation
Reviewed-by: mbalao

! src/share/classes/sun/security/ssl/Alert.java
! src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/CipherType.java
! src/share/classes/sun/security/ssl/ClientHello.java
! src/share/classes/sun/security/ssl/ConnectionContext.java
! src/share/classes/sun/security/ssl/ContentType.java
- src/share/classes/sun/security/ssl/DTLSInputRecord.java
- src/share/classes/sun/security/ssl/DTLSOutputRecord.java
- src/share/classes/sun/security/ssl/DTLSRecord.java
! src/share/classes/sun/security/ssl/Finished.java
! src/share/classes/sun/security/ssl/HandshakeHash.java
! src/share/classes/sun/security/ssl/HelloCookieManager.java
- src/share/classes/sun/security/ssl/HelloVerifyRequest.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/MaxFragExtension.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLCipher.java
! src/share/classes/sun/security/ssl/SSLConfiguration.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLEngineInputRecord.java
! src/share/classes/sun/security/ssl/SSLExtensions.java
! src/share/classes/sun/security/ssl/SSLHandshake.java
! src/share/classes/sun/security/ssl/SSLKeyExchange.java
! src/share/classes/sun/security/ssl/SSLMasterKeyDerivation.java
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/share/classes/sun/security/ssl/SSLSocketInputRecord.java
! src/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java
! src/share/classes/sun/security/ssl/SSLTransport.java
! src/share/classes/sun/security/ssl/ServerHello.java
! src/share/classes/sun/security/ssl/StatusResponseManager.java
! src/share/classes/sun/security/ssl/TransportContext.java

Changeset: a73004866eec
Author:    abakhtin
Date:      2020-08-25 08:39 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a73004866eec

8245470: Fix JDK8 compatibility issues
Reviewed-by: mbalao

! src/share/classes/java/security/MessageDigest.java
! src/share/classes/sun/security/pkcs11/P11Digest.java
! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java
! src/share/classes/sun/security/ssl/CertSignAlgsExtension.java
! src/share/classes/sun/security/ssl/CertStatusExtension.java
! src/share/classes/sun/security/ssl/CertificateVerify.java
! src/share/classes/sun/security/ssl/CookieExtension.java
! src/share/classes/sun/security/ssl/DHClientKeyExchange.java
! src/share/classes/sun/security/ssl/DHServerKeyExchange.java
! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
! src/share/classes/sun/security/ssl/ECDHServerKeyExchange.java
! src/share/classes/sun/security/ssl/Finished.java
! src/share/classes/sun/security/ssl/HandshakeContext.java
! src/share/classes/sun/security/ssl/KeyShareExtension.java
! src/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
! src/share/classes/sun/security/ssl/RSAServerKeyExchange.java
! src/share/classes/sun/security/ssl/RandomCookie.java
! src/share/classes/sun/security/ssl/RenegoInfoExtension.java
! src/share/classes/sun/security/ssl/SSLCipher.java
! src/share/classes/sun/security/ssl/SSLEngineInputRecord.java
! src/share/classes/sun/security/ssl/SSLExtension.java
! src/share/classes/sun/security/ssl/SSLExtensions.java
! src/share/classes/sun/security/ssl/SSLLogger.java
! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/SSLSocketInputRecord.java
! src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! src/share/classes/sun/security/ssl/TransportContext.java
! src/share/classes/sun/security/ssl/Utilities.java
+ src/share/classes/sun/security/util/MessageDigestSpi2.java
! src/share/classes/sun/security/util/SecurityConstants.java

Changeset: 90d302484147
Author:    abakhtin
Date:      2020-08-25 08:41 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/90d302484147

8245471: Revert JDK-8148188
Reviewed-by: mbalao

! src/share/classes/sun/security/ssl/Finished.java

Changeset: b58fdaa80b5a
Author:    abakhtin
Date:      2020-08-25 09:23 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b58fdaa80b5a

8245472: Backport JDK-8038893 to JDK8
Reviewed-by: mbalao

! src/share/classes/java/net/SocketPermission.java
! src/share/classes/sun/net/RegisteredDomain.java
! src/share/classes/sun/security/util/HostnameChecker.java
+ src/share/classes/sun/security/util/RegisteredDomain.java

Changeset: 896bbc5499ff
Author:    abakhtin
Date:      2020-08-25 08:30 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/896bbc5499ff

8245473: OCSP stapling support
Reviewed-by: mbalao

+ src/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java
! src/share/classes/sun/security/validator/PKIXValidator.java
! src/share/classes/sun/security/validator/SimpleValidator.java
! src/share/classes/sun/security/validator/Validator.java

Changeset: 80cdee1da353
Author:    mbalao
Date:      2020-08-25 15:48 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/80cdee1da353

8245474: Add TLS_KRB5 cipher suites support according to RFC-2712
Reviewed-by: aph
Contributed-by: Alexey Bakhtin <alexey at azul.com>, Martin Balao <mbalao at redhat.com>

! make/data/checkdeps/refs.allowed
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/ClientHello.java
! src/share/classes/sun/security/ssl/JsseJce.java
- src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
! src/share/classes/sun/security/ssl/Krb5Helper.java
! src/share/classes/sun/security/ssl/Krb5Proxy.java
+ src/share/classes/sun/security/ssl/KrbClientKeyExchange.java
+ src/share/classes/sun/security/ssl/KrbClientKeyExchangeHelper.java
+ src/share/classes/sun/security/ssl/KrbKeyExchange.java
! src/share/classes/sun/security/ssl/SSLKeyExchange.java
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/share/classes/sun/security/ssl/ServerHello.java
- src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java
- src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java
! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java
+ src/share/classes/sun/security/ssl/krb5/KrbClientKeyExchangeHelperImpl.java

Changeset: ad16e2ef963c
Author:    abakhtin
Date:      2020-08-25 17:53 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ad16e2ef963c

8245476: Disable TLSv1.3 protocol in the ClientHello message by default
Reviewed-by: mbalao

! src/share/classes/sun/security/ssl/SSLContextImpl.java

Changeset: 3ec03c289ff2
Author:    abakhtin
Date:      2020-08-25 16:27 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3ec03c289ff2

8245477: Adjust TLS tests location
Reviewed-by: mbalao

! test/TEST.groups
+ test/com/sun/net/ssl/SSLSecurity/ComKeyManagerFactoryImpl.java
+ test/com/sun/net/ssl/SSLSecurity/ComSSLContextImpl.java
+ test/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
+ test/com/sun/net/ssl/SSLSecurity/JavaxKeyManagerFactoryImpl.java
+ test/com/sun/net/ssl/SSLSecurity/JavaxSSLContextImpl.java
+ test/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
+ test/com/sun/net/ssl/SSLSecurity/ProviderTest.java
+ test/com/sun/net/ssl/SSLSecurity/TruncateArray.java
+ test/javax/net/ssl/ALPN/MyX509ExtendedKeyManager.java
+ test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java
+ test/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java
+ test/javax/net/ssl/ALPN/SSLSocketAlpnTest.java
+ test/javax/net/ssl/Fix5070632.java
+ test/javax/net/ssl/FixingJavadocs/ComURLNulls.java
+ test/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java
+ test/javax/net/ssl/FixingJavadocs/JavaxURLNulls.java
+ test/javax/net/ssl/FixingJavadocs/KMTMGetNothing.java
+ test/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
+ test/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java
+ test/javax/net/ssl/GetInstance.java
+ test/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java
+ test/javax/net/ssl/HttpsURLConnection/DelayDefaultContextLoading.java
+ test/javax/net/ssl/HttpsURLConnection/GetResponseCode.java
+ test/javax/net/ssl/HttpsURLConnection/crisubn.jks
+ test/javax/net/ssl/HttpsURLConnection/trusted.jks
+ test/javax/net/ssl/README
+ test/javax/net/ssl/SSLEngine/AcceptLargeFragments.java
+ test/javax/net/ssl/SSLEngine/ArgCheck.java
+ test/javax/net/ssl/SSLEngine/Arrays.java
+ test/javax/net/ssl/SSLEngine/Basics.java
+ test/javax/net/ssl/SSLEngine/CheckStatus.java
+ test/javax/net/ssl/SSLEngine/ConnectionTest.java
+ test/javax/net/ssl/SSLEngine/ExtendedKeyEngine.java
+ test/javax/net/ssl/SSLEngine/ExtendedKeySocket.java
+ test/javax/net/ssl/SSLEngine/LargeBufs.java
+ test/javax/net/ssl/SSLEngine/LargePacket.java
+ test/javax/net/ssl/SSLEngine/MyX509ExtendedKeyManager.java
+ test/javax/net/ssl/SSLEngine/MyX509KeyManager.java
+ test/javax/net/ssl/SSLEngine/NoAuthClientAuth.java
+ test/javax/net/ssl/SSLEngine/SSLEngineResultArgs.java
+ test/javax/net/ssl/SSLEngine/SSLEngineService.java
+ test/javax/net/ssl/SSLEngine/TestAllSuites.java
+ test/javax/net/ssl/SSLEngineResult/Deserialize.java
+ test/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java
+ test/javax/net/ssl/SSLServerSocket/DefaultSSLServSocketFac.java
+ test/javax/net/ssl/SSLSession/CheckMyTrustedKeystore.java
+ test/javax/net/ssl/SSLSession/HttpsURLConnectionLocalCertificateChain.java
+ test/javax/net/ssl/SSLSession/JSSERenegotiate.java
+ test/javax/net/ssl/SSLSession/KeyManagerTrustManager.java
+ test/javax/net/ssl/SSLSession/SSLCtxAccessToSessCtx.java
+ test/javax/net/ssl/SSLSession/SessionCacheSizeTests.java
+ test/javax/net/ssl/SSLSession/SessionTimeOutTests.java
+ test/javax/net/ssl/SSLSession/testEnabledProtocols.java
! test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java
+ test/javax/net/ssl/ServerName/IllegalSNIName.java
+ test/javax/net/ssl/ServerName/SSLEngineExplorer.java
+ test/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java
+ test/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java
+ test/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java
+ test/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java
+ test/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java
+ test/javax/net/ssl/ServerName/SSLSocketExplorer.java
+ test/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
+ test/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java
+ test/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java
+ test/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java
+ test/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java
+ test/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java
+ test/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
+ test/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java
+ test/javax/net/ssl/TLSv11/ExportableBlockCipher.java
+ test/javax/net/ssl/TLSv11/ExportableStreamCipher.java
+ test/javax/net/ssl/TLSv11/GenericBlockCipher.java
+ test/javax/net/ssl/TLSv11/GenericStreamCipher.java
+ test/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
! test/javax/net/ssl/TLSv12/ProtocolFilter.java
+ test/javax/net/ssl/TLSv12/ShortRSAKey512.java
+ test/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java
+ test/javax/net/ssl/etc/README
+ test/javax/net/ssl/etc/keystore
+ test/javax/net/ssl/etc/truststore
+ test/javax/net/ssl/etc/unknown_keystore
+ test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java
+ test/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
+ test/javax/net/ssl/sanity/ciphersuites/NoKerberos.java
+ test/javax/net/ssl/sanity/interop/CipherTest.java
+ test/javax/net/ssl/sanity/interop/ClientJSSEServerJSSE.java
+ test/javax/net/ssl/sanity/interop/JSSEClient.java
+ test/javax/net/ssl/sanity/interop/JSSEServer.java
+ test/javax/net/ssl/sanity/pluggability/CheckSSLContextExport.java
+ test/javax/net/ssl/sanity/pluggability/CheckSockFacExport1.java
+ test/javax/net/ssl/sanity/pluggability/CheckSockFacExport2.java
+ test/javax/net/ssl/sanity/pluggability/CipherSuites.java
+ test/javax/net/ssl/sanity/pluggability/MySSLContextImpl.java
+ test/javax/net/ssl/sanity/pluggability/MySSLEngineImpl.java
+ test/javax/net/ssl/sanity/pluggability/MySSLServerSocketFacImpl.java
+ test/javax/net/ssl/sanity/pluggability/MySSLSocketFacImpl.java
+ test/javax/net/ssl/templates/SSLCapabilities.java
+ test/javax/net/ssl/templates/SSLEngineTemplate.java
+ test/javax/net/ssl/templates/SSLExplorer.java
+ test/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
! test/sun/net/www/http/HttpClient/B8025710.java
+ test/sun/net/www/protocol/https/AbstractCallback.java
+ test/sun/net/www/protocol/https/ChunkedOutputStream.java
+ test/sun/net/www/protocol/https/ClosedChannelList.java
+ test/sun/net/www/protocol/https/HttpCallback.java
+ test/sun/net/www/protocol/https/HttpTransaction.java
+ test/sun/net/www/protocol/https/HttpsClient/MyKeyManager.java
+ test/sun/net/www/protocol/https/HttpsClient/OriginServer.java
+ test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
+ test/sun/net/www/protocol/https/HttpsClient/ProxyTunnelServer.java
+ test/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
+ test/sun/net/www/protocol/https/HttpsClient/dnsstore
+ test/sun/net/www/protocol/https/HttpsClient/ipstore
+ test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/CheckMethods.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
! test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/OriginServer.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java
+ test/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
+ test/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
+ test/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java
+ test/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java
+ test/sun/net/www/protocol/https/TestHttpsServer.java
! test/sun/security/provider/X509Factory/BadPem.java
! test/sun/security/provider/X509Factory/BigCRL.java
+ test/sun/security/ssl/AppInputStream/ReadBlocksClose.java
+ test/sun/security/ssl/AppInputStream/ReadHandshake.java
+ test/sun/security/ssl/AppInputStream/ReadZeroBytes.java
+ test/sun/security/ssl/AppInputStream/RemoveMarkReset.java
+ test/sun/security/ssl/AppOutputStream/NoExceptionOnClose.java
+ test/sun/security/ssl/CipherSuite/SSL_NULL.java
+ test/sun/security/ssl/ClientHandshaker/CipherSuiteOrder.java
+ test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java
+ test/sun/security/ssl/ClientHandshaker/RSAExport.java
+ test/sun/security/ssl/DHKeyExchange/DHEKeySizing.java
! test/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java
+ test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.java
+ test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.sh
+ test/sun/security/ssl/GenSSLConfigs/ClientThread.java
+ test/sun/security/ssl/GenSSLConfigs/Handler.java
+ test/sun/security/ssl/GenSSLConfigs/ServerHandler.java
+ test/sun/security/ssl/GenSSLConfigs/ServerThread.java
+ test/sun/security/ssl/GenSSLConfigs/TestThread.java
+ test/sun/security/ssl/GenSSLConfigs/Traffic.java
+ test/sun/security/ssl/GenSSLConfigs/main.java
+ test/sun/security/ssl/HandshakeOutStream/NullCerts.java
+ test/sun/security/ssl/InputRecord/ClientHelloRead.java
+ test/sun/security/ssl/InputRecord/OriginServer.java
+ test/sun/security/ssl/InputRecord/ProxyTunnelServer.java
+ test/sun/security/ssl/InputRecord/SSLSocketTimeoutNulls.java
+ test/sun/security/ssl/ProtocolVersion/HttpsProtocols.java
- test/sun/security/ssl/README
+ test/sun/security/ssl/SSLContextImpl/BadKSProvider.java
+ test/sun/security/ssl/SSLContextImpl/BadTSProvider.java
+ test/sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
+ test/sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java
- test/sun/security/ssl/SSLContextImpl/DefautlCacheSize.java
+ test/sun/security/ssl/SSLContextImpl/GoodProvider.java
+ test/sun/security/ssl/SSLContextImpl/IllegalProtocolProperty.java
+ test/sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java
+ test/sun/security/ssl/SSLContextImpl/NoOldVersionContext.java
+ test/sun/security/ssl/SSLContextImpl/NullGetAcceptedIssuers.java
+ test/sun/security/ssl/SSLContextImpl/SSLContextVersion.java
+ test/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java
+ test/sun/security/ssl/SSLEngineImpl/CloseEngineException.java
+ test/sun/security/ssl/SSLEngineImpl/CloseInboundException.java
+ test/sun/security/ssl/SSLEngineImpl/CloseStart.java
+ test/sun/security/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
+ test/sun/security/ssl/SSLEngineImpl/EmptyExtensionData.java
+ test/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
+ test/sun/security/ssl/SSLEngineImpl/RehandshakeFinished.java
+ test/sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
+ test/sun/security/ssl/SSLEngineImpl/SSLEngineDeadlock.java
+ test/sun/security/ssl/SSLSessionContextImpl/DefautlCacheSize.java
+ test/sun/security/ssl/SSLSessionContextImpl/Timeout.java
+ test/sun/security/ssl/SSLSessionImpl/HashCodeMissing.java
+ test/sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
+ test/sun/security/ssl/SSLSocketImpl/CheckMethods.java
+ test/sun/security/ssl/SSLSocketImpl/ClientModeClientAuth.java
+ test/sun/security/ssl/SSLSocketImpl/ClientTimeout.java
+ test/sun/security/ssl/SSLSocketImpl/CloseSocket.java
+ test/sun/security/ssl/SSLSocketImpl/CloseSocketException.java
+ test/sun/security/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
+ test/sun/security/ssl/SSLSocketImpl/LoopbackSSLSocket.java
+ test/sun/security/ssl/SSLSocketImpl/NewSocketMethods.java
+ test/sun/security/ssl/SSLSocketImpl/NoImpactServerRenego.java
+ test/sun/security/ssl/SSLSocketImpl/NonAutoClose.java
+ test/sun/security/ssl/SSLSocketImpl/NotifyHandshakeTest.java
+ test/sun/security/ssl/SSLSocketImpl/NotifyHandshakeTest.policy
+ test/sun/security/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
+ test/sun/security/ssl/SSLSocketImpl/NotifyHandshakeTestHeyYou.java
+ test/sun/security/ssl/SSLSocketImpl/RejectClientRenego.java
+ test/sun/security/ssl/SSLSocketImpl/ReuseAddr.java
+ test/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java
! test/sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java
+ test/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
+ test/sun/security/ssl/SSLSocketImpl/ServerTimeout.java
+ test/sun/security/ssl/SSLSocketImpl/SetClientMode.java
+ test/sun/security/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java
+ test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
+ test/sun/security/ssl/ServerHandshaker/GetPeerHost.java
+ test/sun/security/ssl/ServerHandshaker/GetPeerHostClient.java
+ test/sun/security/ssl/ServerHandshaker/GetPeerHostServer.java
! test/sun/security/ssl/ServerHandshaker/HelloExtensionsTest.java
+ test/sun/security/ssl/SocketCreation/SocketCreation.java
+ test/sun/security/ssl/X509KeyManager/NullCases.java
+ test/sun/security/ssl/X509KeyManager/PreferredKey.java
+ test/sun/security/ssl/X509KeyManager/SelectOneKeyOutOfMany.java
+ test/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
+ test/sun/security/ssl/X509TrustManagerImpl/CertRequestOverflow.java
+ test/sun/security/ssl/X509TrustManagerImpl/CheckNullEntity.java
+ test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java
+ test/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java
+ test/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
+ test/sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java
+ test/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/appleistca2g1-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/appleistca8g1-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/geotrustglobalca-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag2-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag3-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/geotrustuniversalca-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootca-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag2-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag3-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/verisignclass3g3ca-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/verisignclass3g4ca-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-codesigning-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/verisignuniversalrootca-chain.pem
+ test/sun/security/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComKeyManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComSSLContextImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxKeyManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxSSLContextImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/TruncateArray.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/CipherSuite/SSL_NULL.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ClientThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/Handler.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ServerHandler.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ServerThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/TestThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/Traffic.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ClientHelloRead.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/OriginServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ProxyTunnelServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NullGetAcceptedIssuers.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionContextImpl/Timeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CheckMethods.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocket.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/LoopbackSSLSocket.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.policy
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTestHeyYou.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/NullCases.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/PreferredKey.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/SelectOneKeyOutOfMany.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CertRequestOverflow.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CheckNullEntity.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ComodoHacker.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/Distrust.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca2g1-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca8g1-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustglobalca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag2-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag3-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustuniversalca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag2-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag3-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g3ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g4ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-codesigning-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignuniversalrootca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/rsa/BrokenRSAPrivateCrtKey.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/MyKeyManager.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/OriginServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyAuthTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ServerIdentityTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/dnsstore
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ipstore
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/crisubn.jks
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/trusted.jks
- test/sun/security/ssl/etc/README
- test/sun/security/ssl/etc/keystore
- test/sun/security/ssl/etc/truststore
- test/sun/security/ssl/etc/unknown_keystore
- test/sun/security/ssl/javax/net/ssl/ALPN/MyX509ExtendedKeyManager.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLSocketAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/Fix5070632.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ComURLNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/JavaxURLNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/KMTMGetNothing.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java
- test/sun/security/ssl/javax/net/ssl/GetInstance.java
- test/sun/security/ssl/javax/net/ssl/HttpsURLConnection/DelayDefaultContextLoading.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/KeyManagerTrustManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ArgCheck.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Arrays.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Basics.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeyEngine.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/MyX509ExtendedKeyManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/MyX509KeyManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineResultArgs.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java
- test/sun/security/ssl/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java
- test/sun/security/ssl/javax/net/ssl/SSLServerSocket/DefaultSSLServSocketFac.java
- test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
+ test/sun/security/ssl/rsa/BrokenRSAPrivateCrtKey.java
- test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java
- test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
- test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java
- test/sun/security/ssl/sanity/interop/CipherTest.java
- test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java
- test/sun/security/ssl/sanity/interop/JSSEClient.java
- test/sun/security/ssl/sanity/interop/JSSEServer.java
- test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java
- test/sun/security/ssl/sanity/pluggability/CheckSockFacExport1.java
- test/sun/security/ssl/sanity/pluggability/CheckSockFacExport2.java
- test/sun/security/ssl/sanity/pluggability/CipherSuites.java
- test/sun/security/ssl/sanity/pluggability/MySSLContextImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLEngineImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLServerSocketFacImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLSocketFacImpl.java
+ test/sun/security/ssl/spi/ProviderInit.java
- test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java
- test/sun/security/ssl/sun/net/www/httpstest/AbstractCallback.java
- test/sun/security/ssl/sun/net/www/httpstest/ClosedChannelList.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpCallback.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java
- test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CheckMethods.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/OriginServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java
- test/sun/security/ssl/templates/SSLCapabilities.java
- test/sun/security/ssl/templates/SSLEngineTemplate.java
- test/sun/security/ssl/templates/SSLExplorer.java
- test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java
! test/sun/security/ssl/templates/SSLSocketTemplate.java
! test/sun/security/tools/keytool/PrintSSL.java

Changeset: 6c6e8ab540a1
Author:    abakhtin
Date:      2020-08-25 18:03 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6c6e8ab540a1

8245653: Remove 8u TLS tests
Reviewed-by: mbalao

- test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java
- test/javax/net/ssl/FixingJavadocs/ComURLNulls.java
- test/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
- test/javax/net/ssl/SSLEngine/Arrays.java
- test/javax/net/ssl/SSLEngine/CheckStatus.java
- test/javax/net/ssl/SSLEngine/ConnectionTest.java
- test/javax/net/ssl/SSLEngine/ExtendedKeyEngine.java
- test/javax/net/ssl/SSLEngine/IllegalRecordVersion.java
- test/javax/net/ssl/SSLEngine/LargeBufs.java
- test/javax/net/ssl/SSLEngine/NoAuthClientAuth.java
- test/javax/net/ssl/SSLSession/SessionCacheSizeTests.java
- test/javax/net/ssl/SSLSession/SessionTimeOutTests.java
- test/javax/net/ssl/SSLSession/testEnabledProtocols.java
- test/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
- test/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
- test/javax/net/ssl/TLS/CipherTestUtils.java
- test/javax/net/ssl/TLS/JSSEClient.java
- test/javax/net/ssl/TLS/JSSEServer.java
- test/javax/net/ssl/TLS/TLSClientPropertyTest.java
- test/javax/net/ssl/TLS/TestJSSE.java
- test/javax/net/ssl/TLSv11/ExportableBlockCipher.java
- test/javax/net/ssl/TLSv11/ExportableStreamCipher.java
- test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java
- test/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
- test/javax/net/ssl/TLSv12/ShortRSAKey512.java
- test/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
- test/javax/net/ssl/TLSv12/SignatureAlgorithms.java
- test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java
- test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java
- test/javax/net/ssl/etc/README
- test/javax/net/ssl/etc/keystore
- test/javax/net/ssl/etc/truststore
- test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java
- test/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
- test/javax/net/ssl/sanity/interop/CipherTest.java
- test/javax/net/ssl/sanity/interop/ClientJSSEServerJSSE.java
- test/javax/net/ssl/sanity/interop/JSSEClient.java
- test/javax/net/ssl/sanity/interop/JSSEServer.java
- test/javax/net/ssl/templates/SSLEngineTemplate.java
- test/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
- test/javax/net/ssl/templates/SSLSocketTemplate.java
- test/sun/net/www/protocol/https/HttpsClient/OriginServer.java
- test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
- test/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
- test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
! test/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
! test/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
! test/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
! test/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
! test/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
- test/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java
- test/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
- test/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
- test/sun/security/pkcs11/sslecc/CipherTest.java
- test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java
- test/sun/security/pkcs11/sslecc/JSSEClient.java
- test/sun/security/pkcs11/sslecc/JSSEServer.java
- test/sun/security/ssl/AppInputStream/ReadBlocksClose.java
- test/sun/security/ssl/AppInputStream/ReadHandshake.java
- test/sun/security/ssl/AppOutputStream/NoExceptionOnClose.java
- test/sun/security/ssl/CertPathRestrictions/JSSEServer.java
- test/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
- test/sun/security/ssl/CipherSuite/SSL_NULL.java
- test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java
- test/sun/security/ssl/DHKeyExchange/DHEKeySizing.java
- test/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java
- test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.sh
- test/sun/security/ssl/GenSSLConfigs/main.java
! test/sun/security/ssl/HandshakeOutStream/NullCerts.java
- test/sun/security/ssl/InputRecord/SSLSocketTimeoutNulls.java
! test/sun/security/ssl/SSLContextImpl/CustomizedCipherSuites.java
- test/sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
- test/sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java
- test/sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java
- test/sun/security/ssl/SSLContextImpl/NoOldVersionContext.java
- test/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java
- test/sun/security/ssl/SSLEngineImpl/CloseEngineException.java
- test/sun/security/ssl/SSLEngineImpl/CloseInboundException.java
- test/sun/security/ssl/SSLEngineImpl/CloseStart.java
- test/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
- test/sun/security/ssl/SSLEngineImpl/RehandshakeFinished.java
- test/sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
- test/sun/security/ssl/SSLEngineImpl/SSLEngineDeadlock.java
- test/sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
- test/sun/security/ssl/SSLSocketImpl/CheckMethods.java
- test/sun/security/ssl/SSLSocketImpl/ClientTimeout.java
- test/sun/security/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
- test/sun/security/ssl/SSLSocketImpl/NoImpactServerRenego.java
- test/sun/security/ssl/SSLSocketImpl/NonAutoClose.java
- test/sun/security/ssl/SSLSocketImpl/RejectClientRenego.java
- test/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
- test/sun/security/ssl/SSLSocketImpl/SetClientMode.java
- test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
! test/sun/security/ssl/ServerHandshaker/GetPeerHostClient.java
- test/sun/security/ssl/SessionIdCollisionTest.java
- test/sun/security/ssl/SocketCreation/SocketCreation.java
- test/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
- test/sun/security/ssl/X509TrustManagerImpl/CertRequestOverflow.java
- test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java
- test/sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java
- test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java
- test/sun/security/ssl/templates/SSLSocketTemplate.java

Changeset: a39036fa30bb
Author:    abakhtin
Date:      2020-08-25 18:12 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a39036fa30bb

8245681: Add TLSv1.3 regression test from 11.0.7
Reviewed-by: mbalao

+ test/java/security/testlibrary/CertificateBuilder.java
+ test/java/security/testlibrary/SimpleOCSPServer.java
+ test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java
+ test/javax/net/ssl/FixingJavadocs/ComURLNulls.java
+ test/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
+ test/javax/net/ssl/SSLEngine/Arrays.java
+ test/javax/net/ssl/SSLEngine/CheckStatus.java
+ test/javax/net/ssl/SSLEngine/ConnectionTest.java
+ test/javax/net/ssl/SSLEngine/EngineCloseOnAlert.java
+ test/javax/net/ssl/SSLEngine/ExtendedKeyEngine.java
+ test/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java
+ test/javax/net/ssl/SSLEngine/IllegalRecordVersion.java
+ test/javax/net/ssl/SSLEngine/LargeBufs.java
+ test/javax/net/ssl/SSLEngine/NoAuthClientAuth.java
+ test/javax/net/ssl/SSLSession/RenegotiateTLS13.java
+ test/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java
+ test/javax/net/ssl/SSLSession/SessionCacheSizeTests.java
+ test/javax/net/ssl/SSLSession/SessionTimeOutTests.java
+ test/javax/net/ssl/SSLSession/TestEnabledProtocols.java
+ test/javax/net/ssl/SSLSocket/InputStreamClosure.java
+ test/javax/net/ssl/SSLSocket/OutputStreamClosure.java
+ test/javax/net/ssl/SSLSocket/Tls13PacketSize.java
+ test/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
+ test/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
+ test/javax/net/ssl/Stapling/HttpsUrlConnClient.java
+ test/javax/net/ssl/Stapling/SSLEngineWithStapling.java
+ test/javax/net/ssl/Stapling/SSLSocketWithStapling.java
+ test/javax/net/ssl/Stapling/StapleEnableProps.java
+ test/javax/net/ssl/TLS/CipherTestUtils.java
+ test/javax/net/ssl/TLS/JSSEClient.java
+ test/javax/net/ssl/TLS/JSSEServer.java
+ test/javax/net/ssl/TLS/TLSClientPropertyTest.java
+ test/javax/net/ssl/TLS/TLSDataExchangeTest.java
+ test/javax/net/ssl/TLS/TLSEnginesClosureTest.java
+ test/javax/net/ssl/TLS/TLSHandshakeTest.java
+ test/javax/net/ssl/TLS/TLSMFLNTest.java
+ test/javax/net/ssl/TLS/TLSNotEnabledRC4Test.java
+ test/javax/net/ssl/TLS/TLSRehandshakeTest.java
+ test/javax/net/ssl/TLS/TLSRehandshakeWithCipherChangeTest.java
+ test/javax/net/ssl/TLS/TLSRehandshakeWithDataExTest.java
+ test/javax/net/ssl/TLS/TLSUnsupportedCiphersTest.java
+ test/javax/net/ssl/TLS/TestJSSE.java
+ test/javax/net/ssl/TLS/TestJSSEClientDefaultProtocol.java
+ test/javax/net/ssl/TLS/TestJSSEClientProtocol.java
+ test/javax/net/ssl/TLS/TestJSSENoCommonProtocols.java
+ test/javax/net/ssl/TLS/TestJSSEServerProtocol.java
+ test/javax/net/ssl/TLSCommon/BufferOverflowUnderflowTest.java
+ test/javax/net/ssl/TLSCommon/CipherSuite.java
+ test/javax/net/ssl/TLSCommon/ConcurrentClientAccessTest.java
+ test/javax/net/ssl/TLSCommon/DataExchangeTest.java
+ test/javax/net/ssl/TLSCommon/EnginesClosureTest.java
+ test/javax/net/ssl/TLSCommon/HandshakeTest.java
+ test/javax/net/ssl/TLSCommon/KeyAlgorithm.java
+ test/javax/net/ssl/TLSCommon/KeyExAlgorithm.java
+ test/javax/net/ssl/TLSCommon/MFLNTest.java
+ test/javax/net/ssl/TLSCommon/NotEnabledRC4Test.java
+ test/javax/net/ssl/TLSCommon/Protocol.java
+ test/javax/net/ssl/TLSCommon/RehandshakeTest.java
+ test/javax/net/ssl/TLSCommon/RehandshakeWithCipherChangeTest.java
+ test/javax/net/ssl/TLSCommon/RehandshakeWithDataExTest.java
+ test/javax/net/ssl/TLSCommon/SSLEngineTestCase.java
+ test/javax/net/ssl/TLSCommon/TLSTest.java
+ test/javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java
+ test/javax/net/ssl/TLSCommon/UnsupportedCiphersTest.java
+ test/javax/net/ssl/TLSCommon/jaas.conf
+ test/javax/net/ssl/TLSv1/TLSDataExchangeTest.java
+ test/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java
+ test/javax/net/ssl/TLSv1/TLSHandshakeTest.java
+ test/javax/net/ssl/TLSv1/TLSMFLNTest.java
+ test/javax/net/ssl/TLSv1/TLSNotEnabledRC4Test.java
+ test/javax/net/ssl/TLSv1/TLSRehandshakeTest.java
+ test/javax/net/ssl/TLSv1/TLSRehandshakeWithCipherChangeTest.java
+ test/javax/net/ssl/TLSv1/TLSRehandshakeWithDataExTest.java
+ test/javax/net/ssl/TLSv1/TLSUnsupportedCiphersTest.java
+ test/javax/net/ssl/TLSv11/ExportableBlockCipher.java
+ test/javax/net/ssl/TLSv11/ExportableStreamCipher.java
+ test/javax/net/ssl/TLSv11/TLSDataExchangeTest.java
+ test/javax/net/ssl/TLSv11/TLSEnginesClosureTest.java
+ test/javax/net/ssl/TLSv11/TLSHandshakeTest.java
+ test/javax/net/ssl/TLSv11/TLSMFLNTest.java
+ test/javax/net/ssl/TLSv11/TLSNotEnabledRC4Test.java
+ test/javax/net/ssl/TLSv11/TLSRehandshakeTest.java
+ test/javax/net/ssl/TLSv11/TLSRehandshakeWithCipherChangeTest.java
+ test/javax/net/ssl/TLSv11/TLSRehandshakeWithDataExTest.java
+ test/javax/net/ssl/TLSv11/TLSUnsupportedCiphersTest.java
+ test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java
+ test/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
+ test/javax/net/ssl/TLSv12/ShortRSAKey512.java
+ test/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
+ test/javax/net/ssl/TLSv12/SignatureAlgorithms.java
+ test/javax/net/ssl/TLSv12/TLSEnginesClosureTest.java
+ test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java
+ test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java
+ test/javax/net/ssl/compatibility/Cert.java
+ test/javax/net/ssl/compatibility/Client.java
+ test/javax/net/ssl/compatibility/ClientHelloProcessing.java
+ test/javax/net/ssl/compatibility/Compatibility.java
+ test/javax/net/ssl/compatibility/JdkInfo.java
+ test/javax/net/ssl/compatibility/JdkRelease.java
+ test/javax/net/ssl/compatibility/JdkUtils.java
+ test/javax/net/ssl/compatibility/ProcessUtils.java
+ test/javax/net/ssl/compatibility/README
+ test/javax/net/ssl/compatibility/Server.java
+ test/javax/net/ssl/compatibility/Status.java
+ test/javax/net/ssl/compatibility/TestCase.java
+ test/javax/net/ssl/compatibility/UseCase.java
+ test/javax/net/ssl/compatibility/Utils.java
+ test/javax/net/ssl/compatibility/java.security
+ test/javax/net/ssl/etc/README
+ test/javax/net/ssl/etc/keystore
+ test/javax/net/ssl/etc/truststore
+ test/javax/net/ssl/interop/ClientHelloBufferUnderflowException.java
+ test/javax/net/ssl/interop/ClientHelloChromeInterOp.java
+ test/javax/net/ssl/interop/ClientHelloInterOp.java
+ test/javax/net/ssl/sanity/CacertsExplorer.java
+ test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java
+ test/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
+ test/javax/net/ssl/sanity/interop/CipherTest.java
+ test/javax/net/ssl/sanity/interop/ClientJSSEServerJSSE.java
+ test/javax/net/ssl/sanity/interop/JSSEClient.java
+ test/javax/net/ssl/sanity/interop/JSSEServer.java
+ test/javax/net/ssl/templates/SSLContextTemplate.java
+ test/javax/net/ssl/templates/SSLEngineTemplate.java
+ test/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
+ test/javax/net/ssl/templates/SSLSocketTemplate.java
+ test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
+ test/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
+ test/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java
+ test/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
+ test/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
+ test/sun/security/pkcs11/sslecc/CipherTest.java
+ test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java
+ test/sun/security/pkcs11/sslecc/JSSEClient.java
+ test/sun/security/pkcs11/sslecc/JSSEServer.java
+ test/sun/security/pkcs11/sslecc/policy
+ test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java
+ test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java
+ test/sun/security/ssl/AppInputStream/ReadBlocksClose.java
+ test/sun/security/ssl/AppInputStream/ReadHandshake.java
+ test/sun/security/ssl/AppOutputStream/NoExceptionOnClose.java
+ test/sun/security/ssl/CertPathRestrictions/JSSEServer.java
+ test/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
+ test/sun/security/ssl/CipherSuite/SSL_NULL.java
+ test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java
+ test/sun/security/ssl/DHKeyExchange/DHEKeySizing.java
+ test/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java
+ test/sun/security/ssl/DHKeyExchange/UseStrongDHSizes.java
+ test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.sh
+ test/sun/security/ssl/GenSSLConfigs/main.java
+ test/sun/security/ssl/InputRecord/SSLSocketTimeoutNulls.java
+ test/sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
+ test/sun/security/ssl/SSLContextImpl/CustomizedServerDefaultProtocols.java
+ test/sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java
+ test/sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java
+ test/sun/security/ssl/SSLContextImpl/NoOldVersionContext.java
+ test/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java
+ test/sun/security/ssl/SSLEngineImpl/CloseEngineException.java
+ test/sun/security/ssl/SSLEngineImpl/CloseStart.java
+ test/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
+ test/sun/security/ssl/SSLEngineImpl/RehandshakeFinished.java
+ test/sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
+ test/sun/security/ssl/SSLEngineImpl/SSLEngineDeadlock.java
+ test/sun/security/ssl/SSLEngineImpl/SSLEngineFailedALPN.java
+ test/sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java
+ test/sun/security/ssl/SSLEngineImpl/TLS13BeginHandshake.java
+ test/sun/security/ssl/SSLSessionImpl/ResumeChecksClient.java
+ test/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java
+ test/sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
+ test/sun/security/ssl/SSLSocketImpl/CheckMethods.java
+ test/sun/security/ssl/SSLSocketImpl/ClientTimeout.java
+ test/sun/security/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
+ test/sun/security/ssl/SSLSocketImpl/LargePacketAfterHandshakeTest.java
+ test/sun/security/ssl/SSLSocketImpl/NoImpactServerRenego.java
+ test/sun/security/ssl/SSLSocketImpl/NonAutoClose.java
+ test/sun/security/ssl/SSLSocketImpl/RejectClientRenego.java
+ test/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java
+ test/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
+ test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java
+ test/sun/security/ssl/SSLSocketImpl/ServerRenegoWithTwoVersions.java
+ test/sun/security/ssl/SSLSocketImpl/SetClientMode.java
+ test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
+ test/sun/security/ssl/SignatureScheme/Tls13NamedGroups.java
+ test/sun/security/ssl/SocketCreation/SocketCreation.java
+ test/sun/security/ssl/Stapling/StatusResponseManager.java
+ test/sun/security/ssl/Stapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
+ test/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
+ test/sun/security/ssl/X509TrustManagerImpl/CertRequestOverflow.java
+ test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java
+ test/sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java
+ test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java
+ test/sun/security/ssl/internal/TestRun.java
+ test/sun/security/ssl/internal/java.base/sun/security/ssl/TestHkdf.java

Changeset: e329505b1e6a
Author:    mullan
Date:      2017-04-06 16:21 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e329505b1e6a

8161973: PKIXRevocationChecker.getSoftFailExceptions() not working
Reviewed-by: xuelei, mbalao

! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java

Changeset: cf50798dd5a5
Author:    abakhtin
Date:      2020-08-25 18:29 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cf50798dd5a5

8251341: Minimal Java specification change
Reviewed-by: mbalao

! src/share/classes/javax/net/ssl/ExtendedSSLSession.java

Changeset: 0846e98f2db9
Author:    xuelei
Date:      2019-11-08 18:35 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0846e98f2db9

8233621: Mismatch in jsse.enableMFLNExtension property name
Reviewed-by: mullan

! src/share/classes/sun/security/ssl/SSLExtension.java

Changeset: ed0d638da09f
Author:    abakhtin
Date:      2020-08-27 23:21 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ed0d638da09f

8251478: Backport TLSv1.3 regression tests to JDK8u
Reviewed-by: mbalao

! test/javax/net/ssl/FixingJavadocs/ComURLNulls.java
! test/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
! test/javax/net/ssl/SSLSession/RenegotiateTLS13.java
! test/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java
! test/javax/net/ssl/SSLSocket/InputStreamClosure.java
! test/javax/net/ssl/SSLSocket/OutputStreamClosure.java
! test/javax/net/ssl/SSLSocket/Tls13PacketSize.java
! test/javax/net/ssl/Stapling/HttpsUrlConnClient.java
! test/javax/net/ssl/Stapling/SSLEngineWithStapling.java
! test/javax/net/ssl/Stapling/SSLSocketWithStapling.java
! test/javax/net/ssl/Stapling/StapleEnableProps.java
! test/javax/net/ssl/TLS/TLSClientPropertyTest.java
! test/javax/net/ssl/TLS/TLSDataExchangeTest.java
! test/javax/net/ssl/TLS/TLSEnginesClosureTest.java
! test/javax/net/ssl/TLS/TLSHandshakeTest.java
! test/javax/net/ssl/TLS/TLSMFLNTest.java
! test/javax/net/ssl/TLS/TLSNotEnabledRC4Test.java
! test/javax/net/ssl/TLS/TLSRehandshakeTest.java
! test/javax/net/ssl/TLS/TLSRehandshakeWithCipherChangeTest.java
! test/javax/net/ssl/TLS/TLSRehandshakeWithDataExTest.java
! test/javax/net/ssl/TLS/TLSUnsupportedCiphersTest.java
! test/javax/net/ssl/TLS/TestJSSEClientDefaultProtocol.java
! test/javax/net/ssl/TLS/TestJSSEClientProtocol.java
! test/javax/net/ssl/TLS/TestJSSENoCommonProtocols.java
! test/javax/net/ssl/TLS/TestJSSEServerProtocol.java
! test/javax/net/ssl/TLSCommon/Protocol.java
! test/javax/net/ssl/TLSCommon/RehandshakeWithCipherChangeTest.java
! test/javax/net/ssl/TLSCommon/RehandshakeWithDataExTest.java
! test/javax/net/ssl/TLSCommon/SSLEngineTestCase.java
! test/javax/net/ssl/TLSv1/TLSDataExchangeTest.java
! test/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java
! test/javax/net/ssl/TLSv1/TLSHandshakeTest.java
! test/javax/net/ssl/TLSv1/TLSMFLNTest.java
! test/javax/net/ssl/TLSv1/TLSNotEnabledRC4Test.java
! test/javax/net/ssl/TLSv1/TLSRehandshakeTest.java
! test/javax/net/ssl/TLSv1/TLSRehandshakeWithCipherChangeTest.java
! test/javax/net/ssl/TLSv1/TLSRehandshakeWithDataExTest.java
! test/javax/net/ssl/TLSv1/TLSUnsupportedCiphersTest.java
! test/javax/net/ssl/TLSv11/ExportableBlockCipher.java
! test/javax/net/ssl/TLSv11/ExportableStreamCipher.java
! test/javax/net/ssl/TLSv11/TLSDataExchangeTest.java
! test/javax/net/ssl/TLSv11/TLSEnginesClosureTest.java
! test/javax/net/ssl/TLSv11/TLSHandshakeTest.java
! test/javax/net/ssl/TLSv11/TLSMFLNTest.java
! test/javax/net/ssl/TLSv11/TLSNotEnabledRC4Test.java
! test/javax/net/ssl/TLSv11/TLSRehandshakeTest.java
! test/javax/net/ssl/TLSv11/TLSRehandshakeWithCipherChangeTest.java
! test/javax/net/ssl/TLSv11/TLSRehandshakeWithDataExTest.java
! test/javax/net/ssl/TLSv11/TLSUnsupportedCiphersTest.java
! test/javax/net/ssl/TLSv12/TLSEnginesClosureTest.java
! test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java
! test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java
! test/javax/net/ssl/interop/ClientHelloBufferUnderflowException.java
! test/javax/net/ssl/interop/ClientHelloChromeInterOp.java
! test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java
! test/javax/net/ssl/templates/SSLContextTemplate.java
! test/javax/net/ssl/templates/SSLSocketTemplate.java
! test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
! test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
! test/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
! test/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java
! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java
! test/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java
! test/sun/security/provider/certpath/ResponderId/ResponderIdTests.java
! test/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
! test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java
! test/sun/security/ssl/DHKeyExchange/UseStrongDHSizes.java
! test/sun/security/ssl/SSLContextImpl/CustomizedServerDefaultProtocols.java
! test/sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java
! test/sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java
! test/sun/security/ssl/SSLEngineImpl/TLS13BeginHandshake.java
! test/sun/security/ssl/SSLSessionImpl/ResumeChecksClient.java
! test/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java
! test/sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java
! test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
- test/sun/security/ssl/Stapling/StatusResponseManager.java
+ test/sun/security/ssl/Stapling/StatusResponseManager.sh
! test/sun/security/ssl/X509TrustManagerImpl/ClientServer.java
! test/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java
- test/sun/security/ssl/internal/TestRun.java
+ test/sun/security/ssl/internal/TestRun.sh

Changeset: 4546aa3faf37
Author:    andrew
Date:      2020-08-31 06:57 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4546aa3faf37

Merge

- src/share/classes/sun/security/ssl/ALPNExtension.java
- src/share/classes/sun/security/ssl/Alerts.java
- src/share/classes/sun/security/ssl/AppInputStream.java
- src/share/classes/sun/security/ssl/AppOutputStream.java
! src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java
- src/share/classes/sun/security/ssl/ByteBufferInputStream.java
- src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
- src/share/classes/sun/security/ssl/CipherSuiteList.java
- src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/DHClientKeyExchange.java
- src/share/classes/sun/security/ssl/DHCrypt.java
- src/share/classes/sun/security/ssl/Debug.java
! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
- src/share/classes/sun/security/ssl/ECDHCrypt.java
- src/share/classes/sun/security/ssl/EllipticCurvesExtension.java
- src/share/classes/sun/security/ssl/EllipticPointFormatsExtension.java
- src/share/classes/sun/security/ssl/EngineArgs.java
- src/share/classes/sun/security/ssl/EngineInputRecord.java
- src/share/classes/sun/security/ssl/EngineOutputRecord.java
- src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/EphemeralKeyManager.java
! src/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java
- src/share/classes/sun/security/ssl/ExtensionType.java
! src/share/classes/sun/security/ssl/HandshakeHash.java
- src/share/classes/sun/security/ssl/HandshakeInStream.java
- src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
- src/share/classes/sun/security/ssl/HandshakeStateManager.java
- src/share/classes/sun/security/ssl/Handshaker.java
- src/share/classes/sun/security/ssl/HelloExtension.java
- src/share/classes/sun/security/ssl/HelloExtensions.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
- src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
- src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
- src/share/classes/sun/security/ssl/ProtocolList.java
! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
! src/share/classes/sun/security/ssl/RSASignature.java
! src/share/classes/sun/security/ssl/RandomCookie.java
! src/share/classes/sun/security/ssl/Record.java
- src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java
! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/share/classes/sun/security/ssl/SSLAlgorithmDecomposer.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
- src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/ServerNameExtension.java
! src/share/classes/sun/security/ssl/SessionId.java
! src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
- src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
! src/share/classes/sun/security/ssl/TrustStoreManager.java
- src/share/classes/sun/security/ssl/UnknownExtension.java
! src/share/classes/sun/security/ssl/Utilities.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java
- src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java
- src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java
! test/javax/net/ssl/SSLEngine/IllegalRecordVersion.java
! test/javax/net/ssl/TLS/CipherTestUtils.java
! test/javax/net/ssl/TLS/JSSEClient.java
! test/javax/net/ssl/TLS/JSSEServer.java
! test/javax/net/ssl/TLS/TLSClientPropertyTest.java
! test/javax/net/ssl/TLS/TestJSSE.java
! test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java
! test/javax/net/ssl/TLSv12/SignatureAlgorithms.java
! test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java
! test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java
! test/javax/net/ssl/templates/SSLSocketTemplate.java
! test/sun/security/pkcs11/sslecc/CipherTest.java
! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java
! test/sun/security/pkcs11/sslecc/JSSEClient.java
! test/sun/security/pkcs11/sslecc/JSSEServer.java
! test/sun/security/ssl/CertPathRestrictions/JSSEServer.java
! test/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
! test/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java
- test/sun/security/ssl/README
- test/sun/security/ssl/SSLContextImpl/DefautlCacheSize.java
- test/sun/security/ssl/SessionIdCollisionTest.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComKeyManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComSSLContextImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxKeyManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxSSLContextImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/TruncateArray.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/CipherSuite/SSL_NULL.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ClientThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/Handler.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ServerHandler.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ServerThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/TestThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/Traffic.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ClientHelloRead.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/OriginServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ProxyTunnelServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NullGetAcceptedIssuers.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionContextImpl/Timeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CheckMethods.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocket.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/LoopbackSSLSocket.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.policy
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTestHeyYou.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/NullCases.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/PreferredKey.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/SelectOneKeyOutOfMany.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CertRequestOverflow.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CheckNullEntity.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ComodoHacker.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/Distrust.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca2g1-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca8g1-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustglobalca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag2-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag3-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustuniversalca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag2-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag3-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g3ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g4ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-codesigning-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignuniversalrootca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/rsa/BrokenRSAPrivateCrtKey.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/MyKeyManager.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/OriginServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyAuthTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ServerIdentityTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/dnsstore
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ipstore
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/crisubn.jks
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/trusted.jks
- test/sun/security/ssl/etc/README
- test/sun/security/ssl/etc/keystore
- test/sun/security/ssl/etc/truststore
- test/sun/security/ssl/etc/unknown_keystore
- test/sun/security/ssl/javax/net/ssl/ALPN/MyX509ExtendedKeyManager.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLSocketAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/Fix5070632.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ComURLNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/JavaxURLNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/KMTMGetNothing.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java
- test/sun/security/ssl/javax/net/ssl/GetInstance.java
- test/sun/security/ssl/javax/net/ssl/HttpsURLConnection/DelayDefaultContextLoading.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/KeyManagerTrustManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ArgCheck.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Arrays.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Basics.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeyEngine.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/MyX509ExtendedKeyManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/MyX509KeyManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineResultArgs.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java
- test/sun/security/ssl/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java
- test/sun/security/ssl/javax/net/ssl/SSLServerSocket/DefaultSSLServSocketFac.java
- test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
- test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java
- test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
- test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java
- test/sun/security/ssl/sanity/interop/CipherTest.java
- test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java
- test/sun/security/ssl/sanity/interop/JSSEClient.java
- test/sun/security/ssl/sanity/interop/JSSEServer.java
- test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java
- test/sun/security/ssl/sanity/pluggability/CheckSockFacExport1.java
- test/sun/security/ssl/sanity/pluggability/CheckSockFacExport2.java
- test/sun/security/ssl/sanity/pluggability/CipherSuites.java
- test/sun/security/ssl/sanity/pluggability/MySSLContextImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLEngineImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLServerSocketFacImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLSocketFacImpl.java
- test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java
- test/sun/security/ssl/sun/net/www/httpstest/AbstractCallback.java
- test/sun/security/ssl/sun/net/www/httpstest/ClosedChannelList.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpCallback.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java
- test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CheckMethods.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/OriginServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java
- test/sun/security/ssl/templates/SSLCapabilities.java
- test/sun/security/ssl/templates/SSLEngineTemplate.java
- test/sun/security/ssl/templates/SSLExplorer.java
- test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java
- test/sun/security/ssl/templates/SSLSocketTemplate.java

Changeset: e78cf577654b
Author:    andrew
Date:      2020-08-31 07:09 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e78cf577654b

Added tag jdk8u272-b06 for changeset 4546aa3faf37

! .hgtags

Changeset: bd54de1112bf
Author:    andrew
Date:      2020-09-03 06:16 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/bd54de1112bf

Merge jdk8u272-b06

! .hgtags
! THIRD_PARTY_README
! make/mapfiles/libmanagement/mapfile-vers
! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java
! src/share/classes/com/sun/management/OperatingSystemMXBean.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/security/MessageDigest.java
! src/share/classes/sun/security/pkcs11/Secmod.java
! src/share/classes/sun/security/pkcs11/SunPKCS11.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
- src/share/classes/sun/security/ssl/ALPNExtension.java
- src/share/classes/sun/security/ssl/Alerts.java
- src/share/classes/sun/security/ssl/AppInputStream.java
- src/share/classes/sun/security/ssl/AppOutputStream.java
- src/share/classes/sun/security/ssl/ByteBufferInputStream.java
- src/share/classes/sun/security/ssl/CipherBox.java
- src/share/classes/sun/security/ssl/CipherSuiteList.java
- src/share/classes/sun/security/ssl/ClientHandshaker.java
- src/share/classes/sun/security/ssl/DHCrypt.java
- src/share/classes/sun/security/ssl/Debug.java
- src/share/classes/sun/security/ssl/ECDHCrypt.java
- src/share/classes/sun/security/ssl/EllipticCurvesExtension.java
- src/share/classes/sun/security/ssl/EllipticPointFormatsExtension.java
- src/share/classes/sun/security/ssl/EngineArgs.java
- src/share/classes/sun/security/ssl/EngineInputRecord.java
- src/share/classes/sun/security/ssl/EngineOutputRecord.java
- src/share/classes/sun/security/ssl/EngineWriter.java
- src/share/classes/sun/security/ssl/ExtensionType.java
- src/share/classes/sun/security/ssl/HandshakeInStream.java
- src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
- src/share/classes/sun/security/ssl/HandshakeStateManager.java
- src/share/classes/sun/security/ssl/Handshaker.java
- src/share/classes/sun/security/ssl/HelloExtension.java
- src/share/classes/sun/security/ssl/HelloExtensions.java
! src/share/classes/sun/security/ssl/JsseJce.java
- src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
- src/share/classes/sun/security/ssl/MAC.java
- src/share/classes/sun/security/ssl/ProtocolList.java
! src/share/classes/sun/security/ssl/RSASignature.java
! src/share/classes/sun/security/ssl/Record.java
- src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
- src/share/classes/sun/security/ssl/ServerHandshaker.java
- src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
- src/share/classes/sun/security/ssl/UnknownExtension.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
- src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java
- src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/security/validator/Validator.java
! src/share/lib/security/java.security-aix
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
- src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h
! src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h
! test/TEST.groups
! test/sun/security/pkcs11/ec/TestECGenSpec.java
! test/sun/security/pkcs11/ec/TestKeyFactory.java
- test/sun/security/ssl/README
- test/sun/security/ssl/SSLContextImpl/DefautlCacheSize.java
- test/sun/security/ssl/SessionIdCollisionTest.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComKeyManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComSSLContextImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxKeyManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxSSLContextImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java
- test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/TruncateArray.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/CipherSuite/SSL_NULL.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ClientThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/Handler.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ServerHandler.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/ServerThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/TestThread.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/Traffic.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ClientHelloRead.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/OriginServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ProxyTunnelServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NullGetAcceptedIssuers.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionContextImpl/Timeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CheckMethods.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocket.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/LoopbackSSLSocket.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.policy
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTestHeyYou.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/NullCases.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/PreferredKey.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/SelectOneKeyOutOfMany.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CertRequestOverflow.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CheckNullEntity.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ComodoHacker.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/Distrust.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca2g1-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca8g1-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustglobalca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag2-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag3-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustuniversalca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag2-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag3-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g3ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g4ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-codesigning-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignuniversalrootca-chain.pem
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/rsa/BrokenRSAPrivateCrtKey.java
- test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/MyKeyManager.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/OriginServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyAuthTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ServerIdentityTest.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/dnsstore
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ipstore
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/crisubn.jks
- test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/trusted.jks
- test/sun/security/ssl/etc/README
- test/sun/security/ssl/etc/keystore
- test/sun/security/ssl/etc/truststore
- test/sun/security/ssl/etc/unknown_keystore
- test/sun/security/ssl/javax/net/ssl/ALPN/MyX509ExtendedKeyManager.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/ALPN/SSLSocketAlpnTest.java
- test/sun/security/ssl/javax/net/ssl/Fix5070632.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ComURLNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/JavaxURLNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/KMTMGetNothing.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java
- test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java
- test/sun/security/ssl/javax/net/ssl/GetInstance.java
- test/sun/security/ssl/javax/net/ssl/HttpsURLConnection/DelayDefaultContextLoading.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/KeyManagerTrustManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ArgCheck.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Arrays.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Basics.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeyEngine.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/MyX509ExtendedKeyManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/MyX509KeyManager.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineResultArgs.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
- test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java
- test/sun/security/ssl/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java
- test/sun/security/ssl/javax/net/ssl/SSLServerSocket/DefaultSSLServSocketFac.java
- test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java
- test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java
- test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
- test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java
- test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
- test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java
- test/sun/security/ssl/sanity/interop/CipherTest.java
- test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java
- test/sun/security/ssl/sanity/interop/JSSEClient.java
- test/sun/security/ssl/sanity/interop/JSSEServer.java
- test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java
- test/sun/security/ssl/sanity/pluggability/CheckSockFacExport1.java
- test/sun/security/ssl/sanity/pluggability/CheckSockFacExport2.java
- test/sun/security/ssl/sanity/pluggability/CipherSuites.java
- test/sun/security/ssl/sanity/pluggability/MySSLContextImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLEngineImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLServerSocketFacImpl.java
- test/sun/security/ssl/sanity/pluggability/MySSLSocketFacImpl.java
- test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java
- test/sun/security/ssl/sun/net/www/httpstest/AbstractCallback.java
- test/sun/security/ssl/sun/net/www/httpstest/ClosedChannelList.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpCallback.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java
- test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CheckMethods.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/OriginServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java
- test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java
- test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java
- test/sun/security/ssl/templates/SSLCapabilities.java
- test/sun/security/ssl/templates/SSLEngineTemplate.java
- test/sun/security/ssl/templates/SSLExplorer.java
- test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java
- test/sun/security/ssl/templates/SSLSocketTemplate.java

Changeset: 854f27e9f844
Author:    andrew
Date:      2020-09-03 06:17 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/854f27e9f844

Added tag aarch64-shenandoah-jdk8u272-b06 for changeset bd54de1112bf

! .hgtags

Changeset: d8bd882cfd2a
Author:    mbalao
Date:      2020-05-31 10:13 +0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d8bd882cfd2a

8246193: Possible NPE in ENC-PA-REP search in AS-REQ
Reviewed-by: zgu, andrew

! src/share/classes/sun/security/krb5/KrbKdcRep.java
+ test/sun/security/krb5/auto/AlwaysEncPaReq.java
! test/sun/security/krb5/auto/KDC.java

Changeset: ebfae7ddcfc1
Author:    andrew
Date:      2020-09-07 06:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ebfae7ddcfc1

Added tag jdk8u272-b07 for changeset d8bd882cfd2a

! .hgtags

Changeset: 8e05a97cbee8
Author:    andrew
Date:      2020-09-08 13:39 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8e05a97cbee8

Merge jdk8u272-b07

! .hgtags

Changeset: ae57d89ed3bd
Author:    andrew
Date:      2020-09-08 13:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ae57d89ed3bd

Added tag aarch64-shenandoah-jdk8u272-b07 for changeset 8e05a97cbee8

! .hgtags

Changeset: 9deaed6c4a0f
Author:    zgu
Date:      2020-09-09 14:18 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9deaed6c4a0f

8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect
Reviewed-by: dfuchs, martin, robm

! src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java
! src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java
! test/com/sun/jndi/ldap/LdapTimeoutTest.java
! test/com/sun/jndi/ldap/lib/BaseLdapServer.java

Changeset: ab2e99db6702
Author:    zgu
Date:      2020-09-09 14:19 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ab2e99db6702

8062947: Fix exception message to correctly represent LDAP connection failure
Reviewed-by: dfuchs, xyin, vtewari

! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/LdapRequest.java
+ test/com/sun/jndi/ldap/NamingExceptionMessageTest.java

Changeset: 63dd5b7d50eb
Author:    andrew
Date:      2020-09-14 16:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/63dd5b7d50eb

Added tag jdk8u272-b08 for changeset ab2e99db6702

! .hgtags

Changeset: ce694a8afb58
Author:    andrew
Date:      2020-09-16 03:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ce694a8afb58

Merge jdk8u272-b08

! .hgtags
! src/share/classes/com/sun/jndi/ldap/Connection.java

Changeset: 0632eeee979a
Author:    andrew
Date:      2020-09-16 03:34 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0632eeee979a

Added tag aarch64-shenandoah-jdk8u272-b08 for changeset ce694a8afb58

! .hgtags


From shade at redhat.com  Mon Sep 28 07:49:32 2020
From: shade at redhat.com (shade at redhat.com)
Date: Mon, 28 Sep 2020 07:49:32 +0000
Subject: hg: shenandoah/jdk8/hotspot: 21 new changesets
Message-ID: <202009280749.08S7nWXu009531@aojmv0008.oracle.com>

Changeset: 219f17701f43
Author:    coleenp
Date:      2014-12-16 19:00 -0500
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/219f17701f43

8064319: Need to enable -XX:+TraceExceptions in release builds
Summary: "-XX:+TraceExceptions" is now supported in product builds.
Reviewed-by: sla, ccheung, coleenp
Contributed-by: max.ockner at oracle.com

! src/share/vm/runtime/globals.hpp
! test/runtime/CommandLine/TraceExceptionsTest.java

Changeset: 3746571843dd
Author:    valeriep
Date:      2020-05-11 18:49 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3746571843dd

8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26
Summary: Updated from 1.8.24 to 1.8.26
Reviewed-by: xuelei

! THIRD_PARTY_README

Changeset: 1d9ed8dec94c
Author:    sgehwolf
Date:      2020-07-03 15:09 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1d9ed8dec94c

8226575: OperatingSystemMXBean should be made container aware
Reviewed-by: andrew

+ test/runtime/containers/docker/CheckOperatingSystemMXBean.java
! test/runtime/containers/docker/TestCPUAwareness.java
! test/runtime/containers/docker/TestMemoryAwareness.java

Changeset: 9ceaa376784a
Author:    mseledtsov
Date:      2019-03-08 11:08 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9ceaa376784a

8220313: [TESTBUG] Update base image for Docker testing to OL 7.6
Summary: Updated the OL version in Dockerfile in FROM field
Reviewed-by: dcubed

! test/runtime/containers/docker/Dockerfile-BasicTest

Changeset: 9d42d5dfa0cf
Author:    andrew
Date:      2020-08-28 07:32 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9d42d5dfa0cf

Merge


Changeset: 633a3d28d2fe
Author:    andrew
Date:      2020-08-28 07:38 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/633a3d28d2fe

8251120: [8u] HotSpot build assumes ENABLE_JFR is set to either true or false
Summary: Only test for ENABLE_JFR being true, and assume undefined == false
Reviewed-by: neugens

! make/aix/makefiles/buildtree.make
! make/aix/makefiles/vm.make
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/vm.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/vm.make

Changeset: 7b3ade0882f4
Author:    jiefu
Date:      2019-03-01 10:00 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7b3ade0882f4

8219919: RuntimeStub name lost with PrintFrameConverterAssembly
Reviewed-by: kvn

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

Changeset: c7ef664f8649
Author:    shade
Date:      2017-07-18 09:53 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c7ef664f8649

8184762: ZapStackSegments should use optimized memset
Reviewed-by: rkennke, mgerdin

! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/stack.inline.hpp

Changeset: d64fa7b92b5b
Author:    dholmes
Date:      2019-02-08 20:51 -0500
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d64fa7b92b5b

8193234: When using -Xcheck:jni an internally allocated buffer can leak
Reviewed-by: shade, hseigel

! src/share/vm/prims/jniCheck.cpp

Changeset: 34f5c1a4ba37
Author:    mbalao
Date:      2020-08-27 21:00 -0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/34f5c1a4ba37

8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
Summary: Added support for GCM, PSS, and other mechanisms
Reviewed-by: andrew

! THIRD_PARTY_README

Changeset: 4b0aa85a9565
Author:    rkennke
Date:      2020-08-25 13:30 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4b0aa85a9565

8222079: Don't use memset to initialize fields decode_env constructor in disassembler.cpp
Reviewed-by: zgu, andrew

! src/share/vm/compiler/disassembler.cpp

Changeset: 4689eaf1a5c9
Author:    andrew
Date:      2020-08-31 07:09 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4689eaf1a5c9

Added tag jdk8u272-b06 for changeset 4b0aa85a9565

! .hgtags

Changeset: e7780d987def
Author:    andrew
Date:      2020-09-03 06:16 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e7780d987def

Merge jdk8u272-b06

! .hgtags
! THIRD_PARTY_README
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/vm.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/vm.make
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 1766da7f6dd8
Author:    andrew
Date:      2020-09-03 06:17 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1766da7f6dd8

Added tag aarch64-shenandoah-jdk8u272-b06 for changeset e7780d987def

! .hgtags

Changeset: 4ad2d6087d73
Author:    andrew
Date:      2020-09-07 06:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4ad2d6087d73

Added tag jdk8u272-b07 for changeset 4689eaf1a5c9

! .hgtags

Changeset: 356107716c07
Author:    andrew
Date:      2020-09-08 13:39 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/356107716c07

Merge jdk8u272-b07

! .hgtags

Changeset: d7158ff46b9a
Author:    andrew
Date:      2020-09-08 13:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d7158ff46b9a

Added tag aarch64-shenandoah-jdk8u272-b07 for changeset 356107716c07

! .hgtags

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

8252573: 8u: Windows build failed after 8222079 backport
Reviewed-by: sgehwolf, akasko

! src/share/vm/compiler/disassembler.cpp

Changeset: 176a7e5cc060
Author:    andrew
Date:      2020-09-14 16:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/176a7e5cc060

Added tag jdk8u272-b08 for changeset a0eb08e2db5a

! .hgtags

Changeset: 523608cbb5e3
Author:    andrew
Date:      2020-09-16 03:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/523608cbb5e3

Merge jdk8u272-b08

! .hgtags
! src/share/vm/compiler/disassembler.cpp

Changeset: abba30696fb5
Author:    andrew
Date:      2020-09-16 03:34 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/abba30696fb5

Added tag aarch64-shenandoah-jdk8u272-b08 for changeset 523608cbb5e3

! .hgtags


From shade at openjdk.java.net  Mon Sep 28 08:03:12 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Sep 2020 08:03:12 GMT
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent [v2]
In-Reply-To: <yANRqCYyRWZY4F0cAQzTHhD3JxUdbKDGQQHI7iA8VHg=.e0ba11a0-37ff-4f37-a46a-87b4242671d8@github.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
 <yANRqCYyRWZY4F0cAQzTHhD3JxUdbKDGQQHI7iA8VHg=.e0ba11a0-37ff-4f37-a46a-87b4242671d8@github.com>
Message-ID: <GpjnOcrZM6NVC2R_ubIWNCTEuAVT9Ikl9DudBc-J61w=.d8da9a83-2092-4733-8806-bb6f8051178b@github.com>

On Tue, 22 Sep 2020 09:55:56 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> C1 atomic operations are supposed to be sequentially consistent by
>> default but the variant in the Shenandoah C1 barrier set assembler only
>> provides a half-barrier when the CAS succeeds. Added a trailing full
>> barrier and load-acquire to exactly match the non-Shenandoah C1 CAS
>> implementation. This prevents any memory accesses following the CAS
>> operation being observed before it.
>> 
>> Also adjusted the documentation for ShenandoahBarrierSetAssembler
>> ::cmpxchg_oop as it currently claims to be sequentially consistent by
>> default but it's not clear what the "default" values of acquire and
>> release should be, and the comment for acquire/release implies to me
>> that setting them to true would relax the ordering guarantees but
>> actually it's the opposite. I tried to simplify this and make it less
>> ambiguous.
>> 
>> One other thing I noticed when reading this: the comment
>> 
>>    // Step 4. CAS has failed because the value most recently fetched
>>    // from addr (which is now held in tmp1) ...
>> 
>> is wrong on non-LSE systems because tmp1 is rscratch1 and that is
>> clobbered by the call to __ cmpxchg() at the end of step3. Although it
>> doesn't matter because the value in tmp1 is not used after that point.
>> Adjusted the comment to clarify this.
>> 
>> Tested hotspot_all_no_apps, jdk_core plus jcstress with -jvmArgs
>> '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'.
>
> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only insert trailing barrier when is_c1_or_interpreter_only()

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/280

From shade at openjdk.java.net  Mon Sep 28 08:03:12 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Sep 2020 08:03:12 GMT
Subject: RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent [v2]
In-Reply-To: <GpjnOcrZM6NVC2R_ubIWNCTEuAVT9Ikl9DudBc-J61w=.d8da9a83-2092-4733-8806-bb6f8051178b@github.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
 <yANRqCYyRWZY4F0cAQzTHhD3JxUdbKDGQQHI7iA8VHg=.e0ba11a0-37ff-4f37-a46a-87b4242671d8@github.com>
 <GpjnOcrZM6NVC2R_ubIWNCTEuAVT9Ikl9DudBc-J61w=.d8da9a83-2092-4733-8806-bb6f8051178b@github.com>
Message-ID: <CLcOTOXO5Yg01vRQ9X5SCh2hdTXltqoDjWSbHwF7JGg=.6b8500ef-1470-41bd-a79c-d939aaec9281@github.com>

On Mon, 28 Sep 2020 07:59:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only insert trailing barrier when is_c1_or_interpreter_only()
>
> Marked as reviewed by shade (Reviewer).

Sorry for the delay. This looks good, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/280

From stefank at openjdk.java.net  Mon Sep 28 09:13:39 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 28 Sep 2020 09:13:39 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <GT8oZBnnXgccqX30SuUN_56YHrLlubyqgIerG78KP6w=.336244b6-5956-458f-a665-ca50e671c512@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <GT8oZBnnXgccqX30SuUN_56YHrLlubyqgIerG78KP6w=.336244b6-5956-458f-a665-ca50e671c512@github.com>
Message-ID: <9A1_S9rJTFeQMGFbx748OrLxfkxQ6gpbX1fZNhNPFbM=.c4913344-b812-41f3-91b5-61c41c609fe0@github.com>

On Thu, 24 Sep 2020 16:27:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html
>> 
>> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL,
>> PROT_NONE), the function was made aware of exec permissions.
>> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference
>> compared with old code.
>> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and
>> immediately reflects this in diagnostic tools like ps.  For executable regions it would require MAP_FIXED|MAP_JIT, so
>> instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently
>> this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not
>> shrink (if I haven't missed anything, by the implementation and in principle).  Tested:
>> * local tier1
>> * jdk-submit
>> * codesign[2] with hardened runtime and allow-jit but without
>> allow-unsigned-executable-memory entitlements[3] produce a working bundle.
>> 
>> (adding GC group as suggested by @dholmes-ora)
>> 
>> 
>> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227
>> [2]
>>  
>>   codesign \
>>     --sign - \
>>     --options runtime \
>>     --entitlements ents.plist \
>>     --timestamp \
>>     $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib
>> [3]
>>   <?xml version="1.0" encoding="UTF-8"?>
>>   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>>   <plist version="1.0">
>>     <dict>
>>       <key>com.apple.security.cs.allow-jit</key>
>>       <true/>
>>       <key>com.apple.security.cs.disable-library-validation</key>
>>       <true/>
>>       <key>com.apple.security.cs.allow-dyld-environment-variables</key>
>>       <true/>
>>     </dict>
>>   </plist>
>
> I started to look at some of these changes and I have a hunch that we don't ever use MAP_FIXED when reserving memory. I
> have a prototype that cleans that out, but I need more time to complete it and pull it through our testing.

I've now pushed the change to get rid of MAP_FIXED from the reserve memory code:
https://github.com/openjdk/jdk/commit/625a9352bfdc017f426c3bd2a5c24b0f7598ccce

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From ngasson at openjdk.java.net  Mon Sep 28 09:23:21 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 28 Sep 2020 09:23:21 GMT
Subject: Integrated: 8252857: AArch64: Shenandoah C1 CAS is not sequentially
 consistent
In-Reply-To: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
References: <ZSpRYzY13LB9gIMgrKhqhMf7HKTHhgf_yi8Skhty370=.baf68f9a-6127-4c22-8c30-6c879bb6df5d@github.com>
Message-ID: <mUr5xRwQbxMN8FOmd0Q5dMK-MlIjMd54rSVpM1eX5dw=.d8f96624-d97e-43ce-a530-515ce98cbc97@github.com>

On Mon, 21 Sep 2020 09:04:15 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> C1 atomic operations are supposed to be sequentially consistent by
> default but the variant in the Shenandoah C1 barrier set assembler only
> provides a half-barrier when the CAS succeeds. Added a trailing full
> barrier and load-acquire to exactly match the non-Shenandoah C1 CAS
> implementation. This prevents any memory accesses following the CAS
> operation being observed before it.
> 
> Also adjusted the documentation for ShenandoahBarrierSetAssembler
> ::cmpxchg_oop as it currently claims to be sequentially consistent by
> default but it's not clear what the "default" values of acquire and
> release should be, and the comment for acquire/release implies to me
> that setting them to true would relax the ordering guarantees but
> actually it's the opposite. I tried to simplify this and make it less
> ambiguous.
> 
> One other thing I noticed when reading this: the comment
> 
>    // Step 4. CAS has failed because the value most recently fetched
>    // from addr (which is now held in tmp1) ...
> 
> is wrong on non-LSE systems because tmp1 is rscratch1 and that is
> clobbered by the call to __ cmpxchg() at the end of step3. Although it
> doesn't matter because the value in tmp1 is not used after that point.
> Adjusted the comment to clarify this.
> 
> Tested hotspot_all_no_apps, jdk_core plus jcstress with -jvmArgs
> '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'.

This pull request has now been integrated.

Changeset: 8e87d46f
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e87d46f
Stats:     51 lines in 2 files changed: 9 ins; 30 del; 12 mod

8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent

Reviewed-by: rkennke, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/280

From stuefe at openjdk.java.net  Mon Sep 28 10:10:27 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Sep 2020 10:10:27 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
Message-ID: <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>

On Tue, 22 Sep 2020 07:08:35 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html
> 
> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL,
> PROT_NONE), the function was made aware of exec permissions.
> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference
> compared with old code.
> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and
> immediately reflects this in diagnostic tools like ps.  For executable regions it would require MAP_FIXED|MAP_JIT, so
> instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently
> this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not
> shrink (if I haven't missed anything, by the implementation and in principle).  Tested:
> * local tier1
> * jdk-submit
> * codesign[2] with hardened runtime and allow-jit but without
> allow-unsigned-executable-memory entitlements[3] produce a working bundle.
> 
> (adding GC group as suggested by @dholmes-ora)
> 
> 
> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227
> [2]
>  
>   codesign \
>     --sign - \
>     --options runtime \
>     --entitlements ents.plist \
>     --timestamp \
>     $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib
> [3]
>   <?xml version="1.0" encoding="UTF-8"?>
>   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>   <plist version="1.0">
>     <dict>
>       <key>com.apple.security.cs.allow-jit</key>
>       <true/>
>       <key>com.apple.security.cs.disable-library-validation</key>
>       <true/>
>       <key>com.apple.security.cs.allow-dyld-environment-variables</key>
>       <true/>
>     </dict>
>   </plist>

Hi Anton,
 
I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and
inconsistent. There are ongoing efforts to clean this up (see eg JDK-8253650, JDK-8253638 and JDK-8253683). This mess
carries over into the upper layers too, e.g. ReservedSpace.

About the API changes:

- Why does os::uncommit_memory() now require "exec" as parameter? I know why you do it, but semantically it has no
  meaning. I should be able to uncommit memory without knowing the exact flags the mapping had been established with. So
  now the user has to carry this information and provide it back to the API when uncommitting? Right now probably all
  uncommits happen in areas where the exec information is implicit by its usage, but who says this is always the case?

- We now have to specify "exec" as parameter to os::reverve_memory(). This is another new restriction - before, I could
  theoretically reserve one mapping and commit various parts of it with and without exec flag. With this change, the
  whole mapping has to be either exec or !exec.
Can we on MacOS not use mmap at os::commit_memory, like we do on other platforms? In os::commit_memory, the exec
parameter exists but on MacOS it is ignored. It would be more consistent with other platforms if the exec parameter
were honored in commit, not requiring a new one at reserve. And I see mmap is used in uncommit, so changing mappings
via overlapped mmap seems to work?

Thanks, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From stefank at openjdk.java.net  Mon Sep 28 11:20:21 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 28 Sep 2020 11:20:21 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
Message-ID: <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>

On Mon, 28 Sep 2020 11:16:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Anton,
>>  
>> I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and
>> inconsistent. There are ongoing efforts to clean this up (see eg JDK-8253650, JDK-8253638 and JDK-8253683). This mess
>> carries over into the upper layers too, e.g. ReservedSpace.  About the API changes:
>> 
>> - Why does os::uncommit_memory() now require "exec" as parameter? I know why you do it, but semantically it has no
>>   meaning. I should be able to uncommit memory without knowing the exact flags the mapping had been established with. So
>>   now the user has to carry this information and provide it back to the API when uncommitting? Right now probably all
>>   uncommits happen in areas where the exec information is implicit by its usage, but who says this is always the case?
>> 
>> - We now have to specify "exec" as parameter to os::reverve_memory(). This is another new restriction - before, I could
>>   theoretically reserve one mapping and commit various parts of it with and without exec flag. With this change, the
>>   whole mapping has to be either exec or !exec.
>> Can we on MacOS not use mmap at os::commit_memory, like we do on other platforms? In os::commit_memory, the exec
>> parameter exists but on MacOS it is ignored. It would be more consistent with other platforms if the exec parameter
>> were honored in commit, not requiring a new one at reserve. And I see mmap is used in uncommit, so changing mappings
>> via overlapped mmap seems to work?  Thanks, Thomas
>
>> I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and
>> inconsistent.
> 
> Just to clarify that I did not mean your change makes the API convoluted and inconsistent but that it has been that way
> already, for a long time. It is a constant headache to get right, especially in ports whose memory management is a bit
> non-standard, e.g. on AIX.

@tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the
os::reserve_memory changes in this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From stuefe at openjdk.java.net  Mon Sep 28 11:20:21 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Sep 2020 11:20:21 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
Message-ID: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>

On Mon, 28 Sep 2020 10:07:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and
> inconsistent.

Just to clarify that I did not mean your change makes the API convoluted and inconsistent but that it has been that way
already, for a long time. It is a constant headache to get right, especially in ports whose memory management is a bit
non-standard, e.g. on AIX.

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From akozlov at openjdk.java.net  Mon Sep 28 11:58:13 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 28 Sep 2020 11:58:13 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
Message-ID: <DudmT7BSIX3s5Oo3BqayUXl2aZBfTb4d64N3AxtCd8Y=.3a1ced4b-2b66-46f9-b2dc-d7d3e027273f@github.com>

On Mon, 28 Sep 2020 11:17:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>>> I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and
>>> inconsistent.
>> 
>> Just to clarify that I did not mean your change makes the API convoluted and inconsistent but that it has been that way
>> already, for a long time. It is a constant headache to get right, especially in ports whose memory management is a bit
>> non-standard, e.g. on AIX.
>
> @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the
> os::reserve_memory changes in this patch.

Interesting, thanks! I haven't evaluated the interface, just because it seemed to be out of scope for the task. I'll
take a look and update the patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From mbeckwit at openjdk.java.net  Mon Sep 28 13:13:43 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 28 Sep 2020 13:13:43 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v8]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <EN923WYd3gC29aBJeWuZ8hL6s2Eju-SHU-II8ZliD5g=.e3147f7e-b5f6-4309-bfec-dededba26dcf@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
the last revision:

 - Fix graal codestyle
 - Reduce includes
 - Merge remote-tracking branch 'upstream/master' into jdk-windows
 - os_windows: remove duplicated UMA handling
 - test_safefetch{32,N} works fine on win+aarch64
 - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
 - cleanup for 8253457: Remove unimplemented register stack functions
 - Merge remote-tracking branch 'upstream/master' into jdk-windows
 - Update orderAccess_windows_aarch64.hpp
   
   changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
 - 8248787: G1: Workaround MSVC bug
   Reviewed-by:
   Contributed-by: mbeckwit, luhenry, burban
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/4dd32e55...275a0b7f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/68f61d60..275a0b7f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=06-07

  Stats: 25771 lines in 386 files changed: 3908 ins; 20954 del; 909 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Mon Sep 28 13:49:07 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 28 Sep 2020 13:49:07 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com>
 <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com>
Message-ID: <k4SwmbTLzuG5h1O4DZLfPfuwrmBn-jI0ul8_XKB4FUg=.64517d49-4804-4138-b853-de68f22cbefa@github.com>

On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since
>> the last revision:
>>  - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
>>  - cleanup for 8253457: Remove unimplemented register stack functions
>>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>>  - Update orderAccess_windows_aarch64.hpp
>>    
>>    changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided
>>  - 8248787: G1: Workaround MSVC bug
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248670: Windows: Exception handling support on AArch64
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248660: AArch64: Make _clear_cache and _nop portable
>>    Summary: __builtin___clear_cache, etc.
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248659: AArch64: Extend CPU Feature detection
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248656: Add Windows AArch64 platform support code
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - 8248498: Add build system support for Windows AArch64
>>    Reviewed-by:
>>    Contributed-by: mbeckwit, luhenry, burban
>>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/451890eb...2b662010
>
> I looked at changes to existing SA files. These changes look fine.
> 
> I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64
> versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know.
> As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of
> other non-SA files that are new and also have the same copyright issue.
> I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs
> a copyright date update.

@plummercj thank you for your feedback. I've updated the copyright in mentioned files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From mbeckwit at openjdk.java.net  Mon Sep 28 13:48:59 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 28 Sep 2020 13:48:59 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v9]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <jK15vmNZlvvdf3daXpk4PZdywy8YGrirHXW7crRa-X4=.b9686e40-7615-4ead-a575-564259154002@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  SA: update copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/275a0b7f..23b209db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=07-08

  Stats: 5 lines in 5 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From mbeckwit at openjdk.java.net  Mon Sep 28 14:07:16 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 28 Sep 2020 14:07:16 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 24 commits:

 - Merge remote-tracking branch 'upstream/master' into jdk-windows
 - SA: update copyright
 - Fix graal codestyle
 - Reduce includes
 - Merge remote-tracking branch 'upstream/master' into jdk-windows
 - os_windows: remove duplicated UMA handling
 - test_safefetch{32,N} works fine on win+aarch64
 - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
 - cleanup for 8253457: Remove unimplemented register stack functions
 - Merge remote-tracking branch 'upstream/master' into jdk-windows
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6

-------------

Changes: https://git.openjdk.java.net/jdk/pull/212/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=09
  Stats: 2566 lines in 62 files changed: 2208 ins; 126 del; 232 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From github.com+51754783+CoreyAshford at openjdk.java.net  Mon Sep 28 16:46:14 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Mon, 28 Sep 2020 16:46:14 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com>
Message-ID: <aHUkowy9JRJpMoCgT-zwdQVA6nk0WuYloHF--EH4E5k=.25bbec84-9056-48c1-8727-66e4e6acba74@github.com>

On Fri, 25 Sep 2020 13:45:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> src/java.base/share/classes/java/util/Base64.java line 747:
> 
>> 745:          * Decodes base64 characters, and returns the number of data bytes
>> 746:          * produced by the base64 decode intrinsic.
>> 747:          *
> 
> "intrinsic" can be omitted. Both the java and the intrinsic produce the same output.

Good point.  Will fix.

> src/java.base/share/classes/java/util/Base64.java line 759:
> 
>> 757:          * src, it must process a multiple of four of them, making the
>> 758:          * returned destination length a multiple of three.
>> 759:          *
> 
> If the dst array is too short does the intrinsic stop short or throw?
> The java code would throw an ArrayIndexOutOfBoundsException.
> It should not occur since the java code allocates the proper buffer but...
> It might be worth mentioning.

The intrinsic doesn't have enough information to know how long the dst buffer is.  It only knows the starting address
and the offset from that starting address; it has to trust the caller.  encodeBlock() has the same limitation.  I will
add a comment to that effect.

> src/java.base/share/classes/java/util/Base64.java line 820:
> 
>> 818:                     dp += dl;
>> 819:                 }
>> 820:                 if (sp == sl) {
> 
> I'd rather see  (sp >= s1) instead of the equality, its would be consistent with the condition of the while loop.
> (And is already lines 767-768).

Agreed.  Will change that comparison.

> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 260:
> 
>> 258:     }
>> 259:
>> 260:     private static final byte[] nonBase64 = {
> 
> Please add a comment describing this test data.
> (It looks like it could be generated more compactly than an explicit array).
> Ditto nonBase64URL below.

Will do.

> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 240:
> 
>> 238:     }
>> 239:
>> 240:     private static byte[] hexStringToByteArray(String s) {
> 
> A method to convert a Hex String to a byte array already exists in test/lib/jdk/test/lib/Utils.java  in  toByteArray(s).
> Add "jdk.test.lib.Utils" to the "@build" line at the top of the test.

Cool! Thanks.  I was unaware of that function.  Will fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+CoreyAshford at openjdk.java.net  Mon Sep 28 16:46:12 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Mon, 28 Sep 2020 16:46:12 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
Message-ID: <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>

On Sat, 26 Sep 2020 15:33:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> AOT support needs an update:
> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316
> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock
> 
> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557)
> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603)
> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840)
> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55)
> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159)
> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133)
> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766)
> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037)
> 
> Can be reproduced by running JTREG tests:
> compiler/aot/calls/fromAot

Thanks for catching that!  Will fix on next round.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+CoreyAshford at openjdk.java.net  Mon Sep 28 17:20:45 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Mon, 28 Sep 2020 17:20:45 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
Message-ID: <8n1icvS8ly4JNxXsEJe6qT67B53OwHtMFZrc0XrhWzk=.4271b6c1-cf7e-43f9-af86-392f352a2e8c@github.com>

On Mon, 28 Sep 2020 16:35:59 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> AOT support needs an update:
>> #  Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316
>> #  guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock
>> 
>> V  [jvm.dll+0x1dbc6e]  AOTCodeHeap::link_stub_routines_symbols+0xf7e  (aotcodeheap.cpp:557)
>> V  [jvm.dll+0x1d95e8]  AOTCodeHeap::link_global_lib_symbols+0x2f8  (aotcodeheap.cpp:603)
>> V  [jvm.dll+0x1dc616]  AOTCodeHeap::load_klass_data+0x476  (aotcodeheap.cpp:840)
>> V  [jvm.dll+0x1e1021]  AOTLoader::load_for_klass+0x161  (aotloader.cpp:55)
>> V  [jvm.dll+0x5fec96]  InstanceKlass::initialize_impl+0x4e6  (instanceklass.cpp:1159)
>> V  [jvm.dll+0x5fead6]  InstanceKlass::initialize_impl+0x326  (instanceklass.cpp:1133)
>> V  [jvm.dll+0xc5a633]  Threads::initialize_java_lang_classes+0x93  (thread.cpp:3766)
>> V  [jvm.dll+0xc57c32]  Threads::create_vm+0xa12  (thread.cpp:4037)
>> 
>> Can be reproduced by running JTREG tests:
>> compiler/aot/calls/fromAot
>
>> AOT support needs an update:
>> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316
>> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock
>> 
>> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557)
>> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603)
>> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840)
>> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55)
>> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159)
>> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133)
>> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766)
>> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037)
>> 
>> Can be reproduced by running JTREG tests:
>> compiler/aot/calls/fromAot
> 
> Thanks for catching that!  Will fix on next round.

Martin Doerr wrote:
...
> I can see you're using clrldi to clear the upper bits of the parameters. But seems like it clears one bit too few.

You're right.  I misread the instruction as clear from bit 0 to bit N, but it's actually create a mask with bits N to
63 with one's, zeroes elsewhere, then AND it with the src register.

Will fix.

> You can also use cmpwi for the boolean one.

Ah, good!  Thanks.  Will change.

> 
> I wonder about the loop unrolling. It doesn't look beneficial because the loop body is large.
> Did you measure performance gain by this unrolling?
> I think for agressive tuning we'd have to apply techniques like modulo scheduling, but that's much more work.
> So please only use unrolling as far as a benefit is measurable.

I did test on a prototype written in C using vector intrinsics, and 8 was the sweet spot, however the structure of that
code was a bit different and I should have verified that the same amount of loop unrolling makes sense for the Java
intrinsic.   I will perform those experiments.

> 
> But you may want to align the loop start to help instruction fetch.

Interesting.  I did add an align, but in my patch clean up I must have lost it again somehow.  I will add it back
again.  Sorry for that mistake.

> We'll test it, but we don't have Power 10. You guys need to cover that.

I did test on Power10, but I wasn't able to do performance testing because I ran on an instruction-level simulator.
Real hardware will be available in the coming months.

Thanks for your careful look at the code, and the regression testing you've done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From vkempik at openjdk.java.net  Mon Sep 28 17:41:43 2020
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 28 Sep 2020 17:41:43 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
Message-ID: <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>

On Mon, 28 Sep 2020 14:07:16 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains 24 commits:
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - SA: update copyright
>  - Fix graal codestyle
>  - Reduce includes
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - os_windows: remove duplicated UMA handling
>  - test_safefetch{32,N} works fine on win+aarch64
>  - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
>  - cleanup for 8253457: Remove unimplemented register stack functions
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6

src/hotspot/cpu/aarch64/register_aarch64.cpp line 44:

> 42:     "rscratch1", "rscratch2",
> 43:     "r10", "r11", "r12", "r13", "r14", "r15", "r16",
> 44:     "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19",

For me this line doesn't look good in case of expanding this functionality to macos-aarch64
as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Mon Sep 28 19:12:24 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 28 Sep 2020 19:12:24 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
 <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>
Message-ID: <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>

On Mon, 28 Sep 2020 17:37:32 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains 24 commits:
>>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>>  - SA: update copyright
>>  - Fix graal codestyle
>>  - Reduce includes
>>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>>  - os_windows: remove duplicated UMA handling
>>  - test_safefetch{32,N} works fine on win+aarch64
>>  - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc
>>  - cleanup for 8253457: Remove unimplemented register stack functions
>>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>>  - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6
>
> src/hotspot/cpu/aarch64/register_aarch64.cpp line 44:
> 
>> 42:     "rscratch1", "rscratch2",
>> 43:     "r10", "r11", "r12", "r13", "r14", "r15", "r16",
>> 44:     "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19",
> 
> For me this line doesn't look good in case of expanding this functionality to macos-aarch64
> as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18.

The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for
macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS:
Suggestion:

    "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",
Are you suggesting it should rather be something like this eventually?
Suggestion:

    "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From vkempik at openjdk.java.net  Mon Sep 28 19:33:11 2020
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 28 Sep 2020 19:33:11 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
 <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>
 <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
Message-ID: <yAJFEURm2L81tkctj-s1v4S7zIaQNeBerRZlPEsRmbw=.71f93e72-1d17-4a22-b681-f30751b2d2f5@github.com>

On Mon, 28 Sep 2020 19:09:17 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/register_aarch64.cpp line 44:
>> 
>>> 42:     "rscratch1", "rscratch2",
>>> 43:     "r10", "r11", "r12", "r13", "r14", "r15", "r16",
>>> 44:     "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19",
>> 
>> For me this line doesn't look good in case of expanding this functionality to macos-aarch64
>> as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18.
>
> The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for
> macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS:
> Suggestion:
>     "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",
> Are you suggesting it should rather be something like this eventually?
> Suggestion:
> 
>     "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",

this looks better I think, if it's done right from beginning, we won't have to modify it later.
The Question is, can we do it ahead of JEP-391 ?
If we can't then maybe better to leave it this way for now:
WIN64_ONLY("rtls") NOT_WIN64("r18")

as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Mon Sep 28 19:40:49 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 28 Sep 2020 19:40:49 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <yAJFEURm2L81tkctj-s1v4S7zIaQNeBerRZlPEsRmbw=.71f93e72-1d17-4a22-b681-f30751b2d2f5@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
 <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>
 <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
 <yAJFEURm2L81tkctj-s1v4S7zIaQNeBerRZlPEsRmbw=.71f93e72-1d17-4a22-b681-f30751b2d2f5@github.com>
Message-ID: <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com>

On Mon, 28 Sep 2020 19:28:10 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for
>> macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS:
>> Suggestion:
>>     "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",
>> Are you suggesting it should rather be something like this eventually?
>> Suggestion:
>> 
>>     "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",
>
> this looks better I think, if it's done right from beginning, we won't have to modify it later.
> The Question is, can we do it ahead of JEP-391 ?
> If we can't then maybe better to leave it this way for now:
> WIN64_ONLY("rtls") NOT_WIN64("r18")
> 
> as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed.

Let us go with the following in this PR as that's the extend of this PR:
Suggestion:

    "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19",
We can update it accordingly in a PR for JEP-391.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From vkempik at openjdk.java.net  Mon Sep 28 19:44:33 2020
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 28 Sep 2020 19:44:33 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
 <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>
 <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
 <yAJFEURm2L81tkctj-s1v4S7zIaQNeBerRZlPEsRmbw=.71f93e72-1d17-4a22-b681-f30751b2d2f5@github.com>
 <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com>
Message-ID: <D7m4RV4moI0PWEprDrYAmcsf_971Cd6NCNiBzPCUB94=.8fbd4206-854c-4403-97c2-3a98f7d0e6bb@github.com>

On Mon, 28 Sep 2020 19:38:15 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> this looks better I think, if it's done right from beginning, we won't have to modify it later.
>> The Question is, can we do it ahead of JEP-391 ?
>> If we can't then maybe better to leave it this way for now:
>> WIN64_ONLY("rtls") NOT_WIN64("r18")
>> 
>> as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed.
>
> Let us go with the following in this PR as that's the extend of this PR:
> Suggestion:
> 
>     "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19",
> We can update it accordingly in a PR for JEP-391.

Ok, Great.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From mbeckwit at openjdk.java.net  Mon Sep 28 19:53:37 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 28 Sep 2020 19:53:37 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <Yy2r15iisnzHzJnoZd-TFB3zEFIp9ethTlSboItiD-M=.ce77178b-96dd-44df-a04f-13bca10b3f23@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  r18 only on Linux

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/a7cdaad6..398d7645

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From akozlov at openjdk.java.net  Mon Sep 28 20:21:24 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 28 Sep 2020 20:21:24 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <DudmT7BSIX3s5Oo3BqayUXl2aZBfTb4d64N3AxtCd8Y=.3a1ced4b-2b66-46f9-b2dc-d7d3e027273f@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <DudmT7BSIX3s5Oo3BqayUXl2aZBfTb4d64N3AxtCd8Y=.3a1ced4b-2b66-46f9-b2dc-d7d3e027273f@github.com>
Message-ID: <t-UowV5n7aUpxW0HmFDuicBbASwAfkpVFoFXmVc7tRc=.82e2896b-c98b-4502-a495-751d01c2514a@github.com>

On Mon, 28 Sep 2020 11:51:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the
>> os::reserve_memory changes in this patch.
>
> Interesting, thanks! I haven't evaluated the interface, just because it seemed to be out of scope for the task. I'll
> take a look and update the patch.

Hi,

> Can we on MacOS not use mmap at os::commit_memory, like we do on other platforms? In os::commit_memory, the exec
> parameter exists but on MacOS it is ignored.

Unfortunately, no. It's commit_memory uses MAP_FIXED that is incompatible with MAP_JIT. So it is impossible to commit
executable mapping, as commit is always MAP_FIXED. This change proposes a kind of 2-step mapping: MAP_JIT in reserve
and mprotect-without-mmap in commit.

> We now have to specify "exec" as parameter to os::reverve_memory(). This is another new restriction - before, I could
> theoretically reserve one mapping and commit various parts of it with and without exec flag. With this change, the
> whole mapping has to be either exec or !exec.

I think this is a major point in how the interface can be perceived. I assumed reserve to be semantically equivalent to
mmap. And commit/uncommit only to control how much memory is actually allocated in the mmaping. E.g. commit could only
follow reserve and commit could only refer to a (part of) memory reserved. So it would be natural for reserve to
dictate exec or !exec mode for commit in its memory region.

Do you think it will be a bad thing? I.e. to allow exec commit only in exec reserved mapping? Apparently, there was no
demand to do the opposite before. For that, it is still possible to reserve another !exec mapping beside.

> Why does os::uncommit_memory() now require "exec" as parameter? I know why you do it, but semantically it has no
> meaning. I should be able to uncommit memory without knowing the exact flags the mapping had been established with. So
> now the user has to carry this information and provide it back to the API when uncommitting? Right now probably all
> uncommits happen in areas where the exec information is implicit by its usage, but who says this is always the case?

I would propose for reserve, commit, uncommit to take a uniform set of parameters to model an object of a (missing)
"mapping" class, which would contain a meta-information about e.g. permissions. Now the meta-information is available
in the context, as you correctly have noted, so we don't really need to introduce the real object and class.

It is hard for me to imagine a case for "uncommit region regardless exec/!exec permission" that would really justify
the need for such uncommit request.

So I would propose to consider executable and nonexecutable mappings rather different, as 1) it is required by some
platforms like macOS, and 2) it is supported by the fact that now we know the exec/!exec type of a mapping when we work
with it (e.g. heap vs codecache). To continue the trend of the cleanup and to highlight the difference, it is possible
to create specialized code_reserve/commit/uncommit that will be implemented with usual reserve/... on all platforms
except macOS, and latter to use MAP_JIT in the implementation. Or I could stick with exec parameter. What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From eosterlund at openjdk.java.net  Mon Sep 28 20:35:25 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 28 Sep 2020 20:35:25 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v3]
In-Reply-To: <u_WO3mHeUSU2zvWK_csNXQCaUQUzM8TiaIyvkBp2Hzg=.9785a2de-cb18-4008-9191-8fd58f405b4e@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <u_WO3mHeUSU2zvWK_csNXQCaUQUzM8TiaIyvkBp2Hzg=.9785a2de-cb18-4008-9191-8fd58f405b4e@github.com>
Message-ID: <x6je-Um2i3ZLez_X0d3ySHuXnxBK22-WMB_bD6xtlRs=.08b9b7d1-2756-4db3-a5a4-a0c08f28e169@github.com>

On Fri, 25 Sep 2020 04:11:09 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
>> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
>> removed, and callers have been modified.  Testing done:
>> tier1
>> hotspot_gc_shenandoah
>
> Aditya Mandaleeka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few more _raw functions.

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/146

From adityam at openjdk.java.net  Mon Sep 28 20:35:26 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Mon, 28 Sep 2020 20:35:26 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v2]
In-Reply-To: <kj4ORhmVU0mttSm08CNtxDKwtzvJu1nDTDBJoY9R0NE=.d0077a3f-2f25-41a4-b71e-548193b075bf@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <Imzw2fCmzbQ5bURQptgGb2wPa478w2v5qkTC6k2FHww=.6d4ed761-8b65-4fc0-8cb1-a879e157e8f9@github.com>
 <yz8pzus3E_xSZOlnmm-vl0evNXkVfzP6qPUJBXTsPT8=.426c880a-3a64-44c1-bd3b-374250f6cf1f@github.com>
 <kj4ORhmVU0mttSm08CNtxDKwtzvJu1nDTDBJoY9R0NE=.d0077a3f-2f25-41a4-b71e-548193b075bf@github.com>
Message-ID: <YJBuMv7oa7C33iPDi59CarqF1tE5s-cPx4oj_QbcFJ8=.8f524aae-e92e-4efc-8fbd-9f065b762337@github.com>

On Thu, 24 Sep 2020 07:27:17 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Oops seems like I didn't publish the comments somehow.
>
>> Thanks @shipilev and @fisk . I had left `cas_set_mark_raw` alone since there's a caller that specifies
>> `memory_order_release` and I didn't want to change any behavior with the cleanup:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp#L242
>> 
>> That said, I haven't looked into how necessary that is; perhaps it's okay to change it to relaxed order.
>> 
>> 
>> 
>> @fisk Thanks for taking another look. I don't see the new comments you added yet. Have you submitted them?
>> 
>> 
>> 
>> I'll follow up on this PR tomorrow since it's quite late here ??
>> 
>> 
> 
> A lot of thought has gone into the memory ordering flags. This change should definitely not change any of that. Having
> said that, I can't see why we can not rename raw functions to not raw functions, while maintaining the same memory
> ordering.

@fisk Can you please take another look at this when you get a chance?

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From adityam at openjdk.java.net  Mon Sep 28 20:44:51 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Mon, 28 Sep 2020 20:44:51 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v3]
In-Reply-To: <x6je-Um2i3ZLez_X0d3ySHuXnxBK22-WMB_bD6xtlRs=.08b9b7d1-2756-4db3-a5a4-a0c08f28e169@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <u_WO3mHeUSU2zvWK_csNXQCaUQUzM8TiaIyvkBp2Hzg=.9785a2de-cb18-4008-9191-8fd58f405b4e@github.com>
 <x6je-Um2i3ZLez_X0d3ySHuXnxBK22-WMB_bD6xtlRs=.08b9b7d1-2756-4db3-a5a4-a0c08f28e169@github.com>
Message-ID: <z6EvyqUCdhs6DJcwlvqiULLRv2p79QFldxzO2wiyskg=.c1c1925e-db22-4f98-ba64-c00b121138a6@github.com>

On Mon, 28 Sep 2020 20:33:12 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aditya Mandaleeka has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename a few more _raw functions.
>
> Looks good.

Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From adityam at openjdk.java.net  Mon Sep 28 21:42:13 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Mon, 28 Sep 2020 21:42:13 GMT
Subject: RFR: 8251358: Clean up Access configuration after Shenandoah
 barrier change [v3]
In-Reply-To: <z6EvyqUCdhs6DJcwlvqiULLRv2p79QFldxzO2wiyskg=.c1c1925e-db22-4f98-ba64-c00b121138a6@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
 <u_WO3mHeUSU2zvWK_csNXQCaUQUzM8TiaIyvkBp2Hzg=.9785a2de-cb18-4008-9191-8fd58f405b4e@github.com>
 <x6je-Um2i3ZLez_X0d3ySHuXnxBK22-WMB_bD6xtlRs=.08b9b7d1-2756-4db3-a5a4-a0c08f28e169@github.com>
 <z6EvyqUCdhs6DJcwlvqiULLRv2p79QFldxzO2wiyskg=.c1c1925e-db22-4f98-ba64-c00b121138a6@github.com>
Message-ID: <vL_Hze7deZit4hnQG1GantQV8HfxU-FJ1ptcIHMwlyI=.9a21101b-f582-478d-b655-1113a724021b@github.com>

On Mon, 28 Sep 2020 20:42:10 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> Looks good.
>
> Thank you!

Can one of the reviewers please sponsor the change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From gnu.andrew at redhat.com  Tue Sep 29 00:26:03 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 29 Sep 2020 01:26:03 +0100
Subject: [RFR] [8u] 8u272-b09 Upstream Sync
Message-ID: <20200929002603.GD198906@stopbrexit>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/

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

Changes in aarch64-shenandoah-jdk8u272-b09:
  - JDK-8252886: [TESTBUG] sun/security/ec/TestEC.java : Compilation failed

Main issues of note:
None, clean merge (no HotSpot changes).

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/test/sun/security/ec/TestEC.java |    1 +
 2 files changed, 2 insertions(+)

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

Successfully built on x86, x86_64, s390x (Zero), ppc64le, aarch32
(Zero) & aarch64 [0].

Ok to push?

[0] https://koji.fedoraproject.org/koji/buildinfo?buildID=1616531

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 github.com+51754783+CoreyAshford at openjdk.java.net  Tue Sep 29 00:53:59 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Tue, 29 Sep 2020 00:53:59 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
Message-ID: <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>

On Mon, 28 Sep 2020 16:35:59 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> Can be reproduced by running JTREG tests:
> compiler/aot/calls/fromAot

I have tried reproducing this, but haven't yet succeeded.  Here's how I'm running it from the jdk/test directory:

`jtreg -jdk:<path_to_jdk> ./hotspot/jtreg/compiler/aot/calls/fromAot`

The response is this:

Test results: no tests selected
Report written to /home/cjashfor/git-trees/jdk/test/JTreport/html/report.html
Results written to /home/cjashfor/git-trees/jdk/test/JTwork
The report's Results sections shows "Total 0"

Any ideas?  I'm new to running JTReg tests, so don't assume I know anything :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From kbarrett at openjdk.java.net  Tue Sep 29 06:17:38 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 29 Sep 2020 06:17:38 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <wpjH_GtImh2OwB1iTk6I8jOdq7qrSq4Ua3nMDSMhsck=.da4a44d9-8caf-4072-9756-4d2cba1cac4a@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
 <MeZOuoe1unkK3ZYtNhc2ODqvDBYYGUoEOmaHGGosocw=.83d43d8c-d653-48b0-87b1-e996209de3ae@github.com>
 <YuLb1saqpS3gnn8FJ2UXnjDEHU0qYfFcJImutdcfAa0=.0e035ddb-ef64-41ff-95f3-2845036dab57@github.com>
 <wpjH_GtImh2OwB1iTk6I8jOdq7qrSq4Ua3nMDSMhsck=.da4a44d9-8caf-4072-9756-4d2cba1cac4a@github.com>
Message-ID: <i-QS25R7D32rYiG1BHcYTGIM3K8oFWN-3a3fE2n2sEc=.4fcbf869-4f04-44d9-bf17-9d822f4a4e5f@github.com>

On Thu, 24 Sep 2020 13:17:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be
>>> > flagged.
>>> 
>>> It turns out we can't restrict it to unsigned types, at least not very easily. For example,
>>> CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before
>>> calling this, but that seems a little odd. And I don't know how many more there are after
>>> changing that one.
>> 
>> But shouldn't intptr_t be unsigned? I tested with this:
>> 
>> #include <type_traits>
>> #include <stdio.h>
>> 
>> int main() {
>>   printf("%d %d\n", std::is_signed<int>::value, std::is_signed<int*>::value);
>> }
>> 
>> and it prints out "1 0".
>
>> > > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be
>> > > flagged.
>> > 
>> > 
>> > It turns out we can't restrict it to unsigned types, at least not very easily. For example,
>> > CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before
>> > calling this, but that seems a little odd. And I don't know how many more there are after
>> > changing that one.
>> 
>> But shouldn't intptr_t be unsigned? I tested with this:
> 
> Oops, my mistake. I thought `intptr_t` was `int*`, but it's in fact "Integer type capable of holding a value converted
> from a void pointer and then be converted back to that type with a value that compares equal to the original pointer."

Ping.  Needs more reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From thomas.stuefe at gmail.com  Tue Sep 29 06:53:12 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 29 Sep 2020 08:53:12 +0200
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <t-UowV5n7aUpxW0HmFDuicBbASwAfkpVFoFXmVc7tRc=.82e2896b-c98b-4502-a495-751d01c2514a@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <DudmT7BSIX3s5Oo3BqayUXl2aZBfTb4d64N3AxtCd8Y=.3a1ced4b-2b66-46f9-b2dc-d7d3e027273f@github.com>
 <t-UowV5n7aUpxW0HmFDuicBbASwAfkpVFoFXmVc7tRc=.82e2896b-c98b-4502-a495-751d01c2514a@github.com>
Message-ID: <CAA-vtUwD_2vhpV0caex6HuQDQDnjOkKzzmkJ9jV3O3kBKLytRg@mail.gmail.com>

Hi Anton,

On Mon, Sep 28, 2020 at 10:21 PM Anton Kozlov <akozlov at openjdk.java.net>
wrote:

> On Mon, 28 Sep 2020 11:51:24 GMT, Anton Kozlov <akozlov at openjdk.org>
> wrote:
>
> >> @tstuefe My patch to remove MAP_FIXED from the memory reservation path
> should make it possible to revert all the
> >> os::reserve_memory changes in this patch.
> >
> > Interesting, thanks! I haven't evaluated the interface, just because it
> seemed to be out of scope for the task. I'll
> > take a look and update the patch.
>
> Hi,
>
> > Can we on MacOS not use mmap at os::commit_memory, like we do on other
> platforms? In os::commit_memory, the exec
> > parameter exists but on MacOS it is ignored.
>
> Unfortunately, no. It's commit_memory uses MAP_FIXED that is incompatible
> with MAP_JIT. So it is impossible to commit
> executable mapping, as commit is always MAP_FIXED. This change proposes a
> kind of 2-step mapping: MAP_JIT in reserve
> and mprotect-without-mmap in commit.
>

Okay


>
> > We now have to specify "exec" as parameter to os::reverve_memory(). This
> is another new restriction - before, I could
> > theoretically reserve one mapping and commit various parts of it with
> and without exec flag. With this change, the
> > whole mapping has to be either exec or !exec.
>
> I think this is a major point in how the interface can be perceived. I
> assumed reserve to be semantically equivalent to
> mmap. And commit/uncommit only to control how much memory is actually
> allocated in the mmaping. E.g. commit could only
> follow reserve and commit could only refer to a (part of) memory reserved.
> So it would be natural for reserve to
> dictate exec or !exec mode for commit in its memory region.
>

In principle I agree with you. But os::reserve and friends are vaguely
defined wrappers around a number of quite different OS side APIs. Since
they have zero documentation and very little testing, it is everyones guess
what they actually should do. All we have are their names and the various
different implementations, which differ in a lot of details from one
another. I know this since a long time ago I implemented the AIX side of
this API and that was painful.

We have:
1 mmap on most Posix systems. An API with not a lot of restrictions, on the
surface; allows partly unmapping and uncommitting parts; allows to set exec
permissions on a per-page base. But seems not on all OSes.
2 VirtualAlloc on Windows. A stricter API. Only allows unmapping the whole
mapping as a whole.
3 SystemV shared mem. Also strict; also only allows total unmapping. On
Linux used for os::reserve_memory_special (no clue what special means) to
allocate large pages. On AIX, we use it to get 64K pages. On AIX, we
transparently switch between one or the other.

To me, 2 and 3 feel very similar, as opposed to 1.

On Linux and AIX, we dynamically switch between 1 and 3; on AIX we hide
that fact. You are right, there is a missing building block (a mapping
class) which would keep information about a mapping. Arguably,
ReservedSpace feels like it wants to be that building block, but it is
bloated and occupies itself with a lot of heap specific stuff.

On AIX, to get information at commit/release time about the mapping, we
keep such a mapping-related management record internally (struct vmembk_t,
see
https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L1834)
- and retrieve it whenever someone hands in a pointer allocated with
os::reserve_memory, see:
https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L2372
. This code stems from before SAPs involvement in OpenJDK, when we had no
way to change code upstream, and allowed us to hide AIX complications from
upper layers.

This is certainly not the best solution, but it is something you could do
too for MacOS. That would mean you do not have to change the uncommit API.

Of course, a better solution would be a cleanly defined interface, with a
Mapping class which defines properties of a mapping, well documented and
tested :/ but thats a large effort. The small cleanups that are done (most
recently Stefans removal of MAP_FIXED) are a step in that direction.


>
> Do you think it will be a bad thing? I.e. to allow exec commit only in
> exec reserved mapping? Apparently, there was no
> demand to do the opposite before. For that, it is still possible to
> reserve another !exec mapping beside.
>
>
Well, I played with the thought of placing code fragments in Metaspace.
Just an idea now, but being able to set exec permission on a range of
memory would make matters a lot easier. As would not having to care about
exec state of the underlying memory when uncommitting the memory.


> > Why does os::uncommit_memory() now require "exec" as parameter? I know
> why you do it, but semantically it has no
> > meaning. I should be able to uncommit memory without knowing the exact
> flags the mapping had been established with. So
> > now the user has to carry this information and provide it back to the
> API when uncommitting? Right now probably all
> > uncommits happen in areas where the exec information is implicit by its
> usage, but who says this is always the case?
>
> I would propose for reserve, commit, uncommit to take a uniform set of
> parameters to model an object of a (missing)
> "mapping" class, which would contain a meta-information about e.g.
> permissions. Now the meta-information is available
> in the context, as you correctly have noted, so we don't really need to
> introduce the real object and class.
>

But what is the contract here for uncommit (and commit actually)?

It looks like I can change exec permission per page in a mapping
(regardless of its commit state) and it may be able to do this on commit()
- but not on MacOS - but on uncommit, it is just a "remind me again what
flag I used for this mapping" kind of thing. What happens when I
accidentally get it wrong, or there is a mismatch? Something the OS or the
hotspot OS layer should know already.


>
> It is hard for me to imagine a case for "uncommit region regardless
> exec/!exec permission" that would really justify
> the need for such uncommit request.
>

Uncommit has nothing to do with the exec state of the memory. I should not
have to know at uncommit time. Like malloc and free: at free(), I should
not have to know the size of the allocation established with malloc. The
information should be already there in the lower layer. I should not have
to provide it.


> So I would propose to consider executable and nonexecutable mappings
> rather different, as 1) it is required by some
> platforms like macOS,


I could live with that. The platforms which have this restriction are MacOS
and AIX. The latter does not have explicit commit at all, so exec
permission is established at reserve time and cannot be changed later.


> and 2) it is supported by the fact that now we know the exec/!exec type of
> a mapping when we work
> with it (e.g. heap vs codecache).


ok


> To continue the trend of the cleanup and to highlight the difference, it
> is possible
> to create specialized code_reserve/commit/uncommit that will be
> implemented with usual reserve/... on all platforms
> except macOS, and latter to use MAP_JIT in the implementation.


Not totally opposed to this, but how is this different from passing a
parameter?

Which brings me to another thing, if we add exec to os::reserve_memory, why
not to os::reserve_aligned, os::attempt_reserve_at and
os::reserve_memory_special?

We had a similar thing some time ago when (Intel?) introduced the "reserve
heap on device" notion and pushed the "fd" parameter into os::reserve -
into some APIs, but not all, and Stefan Karlson just recently untangled
that mess a bit.


> Or I could stick with exec parameter. What do you think?
>
>
I think we agree that an overhaul would be good, but I do not want to block
you either.

I'd ask you to investigate first if the "exec" information can somehow be
obtained within os_bsd.cpp. Either by asking the platform (maybe there is
an api to get the flags a mapping had been established with?). Or, failing
that, by considering a similar solution as I have outlined above, like what
we did on AIX (could be done better than I did, with less code). Storing
mapping related information in a record and somehow keep it at OS level,
retrieving it as needed.

That would reduce the outside API changes by removing the need to pass in
exec to uncommit. Which really feels wrong to me.

(For the future, a better solution would be an os:: level class for
mappings. Maybe we should just develop a new clean interface beside the old
one and start migrating code to the new one.)

Cheers & thanks for your patience,

 Thomas



> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/294
>

From dholmes at openjdk.java.net  Tue Sep 29 06:57:02 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Sep 2020 06:57:02 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11]
In-Reply-To: <Yy2r15iisnzHzJnoZd-TFB3zEFIp9ethTlSboItiD-M=.ce77178b-96dd-44df-a04f-13bca10b3f23@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <Yy2r15iisnzHzJnoZd-TFB3zEFIp9ethTlSboItiD-M=.ce77178b-96dd-44df-a04f-13bca10b3f23@github.com>
Message-ID: <vRHnhBqsQfoOBtgStTmtHwmFtovuceinU-VOu4bGsBg=.aa653fd1-0620-46a7-a52c-43101d318704@github.com>

On Mon, 28 Sep 2020 19:53:37 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   r18 only on Linux

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From stefank at openjdk.java.net  Tue Sep 29 07:15:38 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 29 Sep 2020 07:15:38 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
Message-ID: <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>

On Mon, 28 Sep 2020 11:17:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the
> os::reserve_memory changes in this patch.

FWIW, I now understand that the motivation for the changes in os::reserve_memory is *not* that *it* uses MAP_FIXED.
Instead the change there is done so that os::commit_memory doesn't have to mix mmap + MAP_FIXED + MAP_JIT. This is also
the reason why os::uncommit_memory needs to be changed as well. So, ignore my comment above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/294

From adityam at openjdk.java.net  Tue Sep 29 07:28:11 2020
From: adityam at openjdk.java.net (Aditya Mandaleeka)
Date: Tue, 29 Sep 2020 07:28:11 GMT
Subject: Integrated: 8251358: Clean up Access configuration after Shenandoah
 barrier change
In-Reply-To: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
References: <P4shuw5sKp2YR_gf0XrklqdrFkgNGo0xPPX4h5TwocA=.6294955c-72bc-4caf-8082-7538c2101bcf@github.com>
Message-ID: <do-vbHEMXjlhFSw8WHybH4mfOvpcJkVwDQzqfVtmyLE=.68d3c40c-7c35-4054-82d7-c24a11def3a6@github.com>

On Mon, 14 Sep 2020 05:16:11 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

> This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the
> `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been
> removed, and callers have been modified.  Testing done:
> tier1
> hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: e63b90cc
Author:    Aditya Mandaleeka <adityam at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e63b90cc
Stats:     202 lines in 38 files changed: 0 ins; 92 del; 110 mod

8251358: Clean up Access configuration after Shenandoah barrier change

Reviewed-by: eosterlund, rkennke, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/146

From mdoerr at openjdk.java.net  Tue Sep 29 08:59:45 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 29 Sep 2020 08:59:45 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
Message-ID: <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>

On Tue, 29 Sep 2020 00:51:37 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>>> AOT support needs an update:
>>> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316
>>> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock
>>> 
>>> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557)
>>> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603)
>>> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840)
>>> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55)
>>> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159)
>>> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133)
>>> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766)
>>> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037)
>>> 
>>> Can be reproduced by running JTREG tests:
>>> compiler/aot/calls/fromAot
>> 
>> Thanks for catching that!  Will fix on next round.
>
>> Can be reproduced by running JTREG tests:
>> compiler/aot/calls/fromAot
> 
> I have tried reproducing this, but haven't yet succeeded.  Here's how I'm running it from the jdk/test directory:
> 
> `jtreg -jdk:<path_to_jdk> ./hotspot/jtreg/compiler/aot/calls/fromAot`
> 
> The response is this:
> 
> Test results: no tests selected
> Report written to /home/cjashfor/git-trees/jdk/test/JTreport/html/report.html
> Results written to /home/cjashfor/git-trees/jdk/test/JTwork
> The report's Results sections shows "Total 0"
> 
> Any ideas?  I'm new to running JTReg tests, so don't assume I know anything :)

Did you try on x86? AOT is not supported on PPC64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From aph at redhat.com  Tue Sep 29 09:24:35 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Sep 2020 10:24:35 +0100
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
 <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>
 <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
Message-ID: <2f5093a5-2e1b-6ce9-3fc9-2c036261218f@redhat.com>

On 28/09/2020 20:12, Bernhard Urban-Forster wrote:
> The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for
> macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS:
> Suggestion:
> 
>     "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",
> Are you suggesting it should rather be something like this eventually?
> Suggestion:
> 
>     "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",

This wrong. We can't use the register in Linux only, except in Linux-specific
code of which there is almost none. It should be called r18_tls everywhere,
as discussed.

-- 
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  Tue Sep 29 09:26:31 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Sep 2020 10:26:31 +0100
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]
In-Reply-To: <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com>
 <mw3x-2JS3lzIYeZ31QUUNff0IdAS4R4PhbA58pceyJA=.d7ef624b-7d8c-43e8-9002-1c9467294e80@github.com>
 <xjfCFcCHAabHtkHegVIHYWxQcBNagpySsuD1ImVvY4M=.d6c236f8-66ce-4977-8d3f-bf115c7e35ec@github.com>
Message-ID: <fa185575-7dcd-a575-78e2-9d0d5d83954c@redhat.com>

On 28/09/2020 20:12, Bernhard Urban-Forster wrote:
> The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for
> macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS:
> Suggestion:
>
>     "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",
> Are you suggesting it should rather be something like this eventually?
> Suggestion:
>
>     "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19",

This is wrong. We can't use the register in Linux either, except in
Linux-specific code of which there is almost none. It's also a
pointless complication. r18 should be called r18_tls everywhere, as
discussed.

-- 
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 ihse at openjdk.java.net  Tue Sep 29 11:16:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 29 Sep 2020 11:16:06 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11]
In-Reply-To: <Yy2r15iisnzHzJnoZd-TFB3zEFIp9ethTlSboItiD-M=.ce77178b-96dd-44df-a04f-13bca10b3f23@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <Yy2r15iisnzHzJnoZd-TFB3zEFIp9ethTlSboItiD-M=.ce77178b-96dd-44df-a04f-13bca10b3f23@github.com>
Message-ID: <R1Z8Y4kmkO9HEIhc70sohOjTAyR-tM3yR_doyrRWzko=.3daac681-22c9-4f89-a321-592dd4145295@github.com>

On Mon, 28 Sep 2020 19:53:37 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   r18 only on Linux

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/212

From thomas.stuefe at gmail.com  Tue Sep 29 11:20:47 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 29 Sep 2020 13:20:47 +0200
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <7128d909-fdd3-6ab4-5347-c262fa6216fe@azul.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <DudmT7BSIX3s5Oo3BqayUXl2aZBfTb4d64N3AxtCd8Y=.3a1ced4b-2b66-46f9-b2dc-d7d3e027273f@github.com>
 <t-UowV5n7aUpxW0HmFDuicBbASwAfkpVFoFXmVc7tRc=.82e2896b-c98b-4502-a495-751d01c2514a@github.com>
 <CAA-vtUwD_2vhpV0caex6HuQDQDnjOkKzzmkJ9jV3O3kBKLytRg@mail.gmail.com>
 <7128d909-fdd3-6ab4-5347-c262fa6216fe@azul.com>
Message-ID: <CAA-vtUwwSE2zTA2dL=_pP6_4jBC+XyQCbd=v2kof_HU7duB=zA@mail.gmail.com>

Hi Anton,

Excuse me for the long message. I'll take a look is it possible to retrieve
> the information in runtime and look for the options.


just another thought, in uncommit, if there is no way to poll the creation
flag from the OS, you could just first try mmap(MAP_FIXED, MAP_NORESERVE);
if that fails due to EINVAL, try the madvise route.

Cheers, Thomas


>

From stefank at openjdk.java.net  Tue Sep 29 12:42:49 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 29 Sep 2020 12:42:49 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
Message-ID: <m1gL9hpAgwkYxxGMXVd2yCCqaUDgxd1JyQHc5UPIl9o=.f3ea6ced-4842-4aa8-afe1-0b03e9148105@github.com>

On Tue, 22 Sep 2020 13:43:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the type narrowOop from a typedef for juint to a
>> scoped enum with uint32_t as the representation type.  This provides stronger
>> type checking when using this type.
>> 
>> For the most part this was fairly straightforward, and the patch size is
>> relatively small.  The implementation of some existing CompressedOops
>> "primitives" required adjustment. An explicit conversion to narrowOop was
>> added, with casts change to use it.  There were a few places that were type
>> punning and needed explicit conversions,, mostly in platform-specific assembly
>> support.
>> 
>> There are a couple of lingering problems.
>> 
>> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
>> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
>> this probably ought to be done differently.
>> 
>> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
>> whether these can be safely converted to CompressedOops::narrow_oop_cast.
>> 
>> There might still be some casts from narrowOop to an integral type.  Those are
>> hard to find in our cast-happy code base.
>> 
>> Testing:
>> tier1-6 for Oracle supported platforms.
>> Build fastdebug linux-ppc64le and linux-s390x.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - improve assertion
>  - remove NarrowType

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179:

> 177:     // Move narrow OOP
> 178:     narrowOop noop = CompressedOops::encode((oop)o);
> 179:     uint32_t n = CompressedOops::narrow_oop_value(noop);

I wonder if we should simply create an overload for oop so that this (and the other places) could be changed to:
 n = CompressedOops::narrow_oop_value((oop)o);```

src/hotspot/cpu/ppc/relocInfo_ppc.cpp line 62:

> 60:       narrowOop no = (type() == relocInfo::oop_type) ?
> 61:           CompressedOops::encode((oop)x) :
> 62:           // FIXME: Cheating! Treating narrowKlass as a narrowOop.

I think we try to avoid adding new FIXMES and TODOS to the code. Maybe create a JBS entry instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/273

From akozlov at azul.com  Tue Sep 29 10:50:11 2020
From: akozlov at azul.com (Anton Kozlov)
Date: Tue, 29 Sep 2020 13:50:11 +0300
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS
In-Reply-To: <CAA-vtUwD_2vhpV0caex6HuQDQDnjOkKzzmkJ9jV3O3kBKLytRg@mail.gmail.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <DudmT7BSIX3s5Oo3BqayUXl2aZBfTb4d64N3AxtCd8Y=.3a1ced4b-2b66-46f9-b2dc-d7d3e027273f@github.com>
 <t-UowV5n7aUpxW0HmFDuicBbASwAfkpVFoFXmVc7tRc=.82e2896b-c98b-4502-a495-751d01c2514a@github.com>
 <CAA-vtUwD_2vhpV0caex6HuQDQDnjOkKzzmkJ9jV3O3kBKLytRg@mail.gmail.com>
Message-ID: <7128d909-fdd3-6ab4-5347-c262fa6216fe@azul.com>



On 29.09.2020 09:53, Thomas St?fe wrote:
> On AIX, to get information at commit/release time about the mapping, we
> keep such a mapping-related management record internally (struct vmembk_t,
> see
> https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L1834)
> - and retrieve it whenever someone hands in a pointer allocated with
> os::reserve_memory, see:
> https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L2372
> . This code stems from before SAPs involvement in OpenJDK, when we had no
> way to change code upstream, and allowed us to hide AIX complications from
> upper layers.
> 
> This is certainly not the best solution, but it is something you could do
> too for MacOS. That would mean you do not have to change the uncommit API.
>
> Uncommit has nothing to do with the exec state of the memory. I should not
> have to know at uncommit time. Like malloc and free: at free(), I should
> not have to know the size of the allocation established with malloc. The
> information should be already there in the lower layer. I should not have
> to provide it.

Thanks for pointing, I'll take a deeper look. 

In general, I'm trying to avoid such kind of bookkeeping, because it is
overhead (in CPU and memory). An API change could render this overhead to 
nothing, and I think this is a good thing even at cost of more complicated 
API (not saying bad API :). I'm not sure we can always avoid complicated API.
It abstracts different operating systems and also needs to do that
efficiently.
I find malloc/free analogy is useful. Free don't need the size parameter because it is possible to rather efficiently store (small overhead) the size 
beside the allocated block. But I'm not sure our interface needs to provide
the same level of generality. All our users are nearby and wecan always fix 
them or interface.

> Of course, a better solution would be a cleanly defined interface, with a
> Mapping class which defines properties of a mapping, well documented and
> tested :/ but thats a large effort. The small cleanups that are done (most
> recently Stefans removal of MAP_FIXED) are a step in that direction.

Agree, I think it possible to do Mapping so it would have minimal runtime
overhead, so probably it will emerge sometime.

>> Do you think it will be a bad thing? I.e. to allow exec commit only in
>> exec reserved mapping? 
>>
> Well, I played with the thought of placing code fragments in Metaspace.
> Just an idea now, but being able to set exec permission on a range of
> memory would make matters a lot easier. As would not having to care about
> exec state of the underlying memory when uncommitting the memory.

I would suggest a metaspace-code section beside here :)

>> To continue the trend of the cleanup and to highlight the difference, it
>> is possible
>> to create specialized code_reserve/commit/uncommit that will be
>> implemented with usual reserve/... on all platforms
>> except macOS, and latter to use MAP_JIT in the implementation.
> 
> 
> Not totally opposed to this, but how is this different from passing a
> parameter?
> 
> Which brings me to another thing, if we add exec to os::reserve_memory, why
> not to os::reserve_aligned, os::attempt_reserve_at and
> os::reserve_memory_special?

The questions are related, I think. Semantically the new set of functions 
(code_reserve,...) will not be a big difference. But the specialized function
would allow defining a clean API that is tied to use-case. So there will be 
no code_reserve_at, code_attemp_reserve,.. 

> But what is the contract here for uncommit (and commit actually)?
> 
> It looks like I can change exec permission per page in a mapping
> (regardless of its commit state) and it may be able to do this on commit()
> - but not on MacOS - but on uncommit, it is just a "remind me again what
> flag I used for this mapping" kind of thing. What happens when I
> accidentally get it wrong, or there is a mismatch? Something the OS or the
> hotspot OS layer should know already.

Yes, this is a good point. I don't have an immediate answer. Mapping class 
could solve this. To some extend, code_reserve and friends could also do 
that, because it is harder to confuse code_{reserve,commit,uncommit} 
functions and general ones.

>> Or I could stick with exec parameter. What do you think?
>>
>>
> I think we agree that an overhaul would be good, but I do not want to block
> you either.
> 
> I'd ask you to investigate first if the "exec" information can somehow be
> obtained within os_bsd.cpp. Either by asking the platform (maybe there is
> an api to get the flags a mapping had been established with?). Or, failing
> that, by considering a similar solution as I have outlined above, like what
> we did on AIX (could be done better than I did, with less code). Storing
> mapping related information in a record and somehow keep it at OS level,
> retrieving it as needed.
> 
> That would reduce the outside API changes by removing the need to pass in
> exec to uncommit. Which really feels wrong to me.
> 
> (For the future, a better solution would be an os:: level class for
> mappings. Maybe we should just develop a new clean interface beside the old
> one and start migrating code to the new one.)
> 
> Cheers & thanks for your patience,

Excuse me for the long message. I'll take a look is it possible to retrieve 
the information in runtime and look for the options. I think it should be 
there something, but it depends on the possible overhead.
Thanks,
Anton


From mbeckwit at openjdk.java.net  Tue Sep 29 14:08:49 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 29 Sep 2020 14:08:49 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  change string representation for r18 to "r18_tls" on every platform

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/212/files
  - new: https://git.openjdk.java.net/jdk/pull/212/files/398d7645..15466ab2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/212.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212

PR: https://git.openjdk.java.net/jdk/pull/212

From burban at openjdk.java.net  Tue Sep 29 14:08:50 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Tue, 29 Sep 2020 14:08:50 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]
In-Reply-To: <Pw93XXVvMMvh-dPGMWn2hDsQaZB8N8zr5GoxWG7a-Qc=.57eac20d-4cd3-4644-a8a1-35a210d5da07@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com>
 <Pw93XXVvMMvh-dPGMWn2hDsQaZB8N8zr5GoxWG7a-Qc=.57eac20d-4cd3-4644-a8a1-35a210d5da07@github.com>
Message-ID: <xpBv0IIGgmYsYP8pDEgQFh2KilMDcertw8ZMbJqetsk=.488a2405-33ec-4b2e-8871-63273ad1e47f@github.com>

On Fri, 25 Sep 2020 12:44:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - os_windows: remove duplicated UMA handling
>>  - test_safefetch{32,N} works fine on win+aarch64
>
> Marked as reviewed by aph (Reviewer).

@theRealAph okay, I've changed the string representation of `r18` to `"r18_tls"` on every platform.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From github.com+51754783+CoreyAshford at openjdk.java.net  Tue Sep 29 16:42:03 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Tue, 29 Sep 2020 16:42:03 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
Message-ID: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>

On Tue, 29 Sep 2020 08:41:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Did you try on x86? AOT is not supported on PPC64.

I didn't.  No wonder.  Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From cjplummer at openjdk.java.net  Tue Sep 29 20:11:19 2020
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 29 Sep 2020 20:11:19 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]
In-Reply-To: <xpBv0IIGgmYsYP8pDEgQFh2KilMDcertw8ZMbJqetsk=.488a2405-33ec-4b2e-8871-63273ad1e47f@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com>
 <Pw93XXVvMMvh-dPGMWn2hDsQaZB8N8zr5GoxWG7a-Qc=.57eac20d-4cd3-4644-a8a1-35a210d5da07@github.com>
 <xpBv0IIGgmYsYP8pDEgQFh2KilMDcertw8ZMbJqetsk=.488a2405-33ec-4b2e-8871-63273ad1e47f@github.com>
Message-ID: <jngdyceA_08TPUKjEwjdklOGOKV_3EHMqdqjCRq-EVA=.efc92b2a-8b37-424e-93d6-04e38a6d9754@github.com>

On Tue, 29 Sep 2020 14:03:57 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Marked as reviewed by aph (Reviewer).
>
> @theRealAph okay, I've changed the string representation of `r18` to `"r18_tls"` on every platform.

> @plummercj thank you for your feedback. I've updated the copyright in mentioned files.

Changes look good. Thanks. I'm marking as "reviewed" for serviceability changes and copyrights.

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From cjplummer at openjdk.java.net  Tue Sep 29 20:16:24 2020
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 29 Sep 2020 20:16:24 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
Message-ID: <K66-1vVWwEKIfHuyNESStvB9rUEf-8JRITHbhjxJFF0=.a42bd19b-47c4-4df0-86c0-17676b27619a@github.com>

On Tue, 29 Sep 2020 14:08:49 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change string representation for r18 to "r18_tls" on every platform

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From dholmes at openjdk.java.net  Wed Sep 30 00:43:13 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Sep 2020 00:43:13 GMT
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
Message-ID: <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>

On Tue, 29 Sep 2020 14:08:49 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change string representation for r18 to "r18_tls" on every platform

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/212

From shade at openjdk.java.net  Wed Sep 30 07:28:38 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Sep 2020 07:28:38 GMT
Subject: RFR: 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint should
 not access VMThread state from other threads
Message-ID: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>

There are lots of Shenandoah-related test failures in current runs, triggered by new assert in JDK-8212107. The assert
looks legitimate, and Shenandoah code should instead be more relaxed here, by checking it runs in VMThread before
accessing its state.

Testing:
  - [x] hotspot_gc_shenandoah

-------------

Commit messages:
 - Comments
 - 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint should not access VMThread state from other threads

Changes: https://git.openjdk.java.net/jdk/pull/424/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=424&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253778
  Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/424/head:pull/424

PR: https://git.openjdk.java.net/jdk/pull/424

From shade at openjdk.java.net  Wed Sep 30 07:47:32 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Sep 2020 07:47:32 GMT
Subject: RFR: 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint
 should not access VMThread state from other threads [v2]
In-Reply-To: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>
References: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>
Message-ID: <OeVc5dTShypEPycaa3Wb8MWjpjh7bYLB8eOpM-KTWiI=.fecd58fe-c77a-4c50-a620-0a5f1f0da37d@github.com>

> There are lots of Shenandoah-related test failures in current runs, triggered by new assert in JDK-8212107. The assert
> looks legitimate, and Shenandoah code should instead be more relaxed here, by checking it runs in VMThread before
> accessing its state.  Testing:
>   - [x] hotspot_gc_shenandoah

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Revert the not very valid change

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/424/files
  - new: https://git.openjdk.java.net/jdk/pull/424/files/054c5840..fe406017

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=424&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=424&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/424/head:pull/424

PR: https://git.openjdk.java.net/jdk/pull/424

From jiefu at openjdk.java.net  Wed Sep 30 07:55:58 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 30 Sep 2020 07:55:58 GMT
Subject: RFR: 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint
 should not access VMThread state from other threads [v2]
In-Reply-To: <OeVc5dTShypEPycaa3Wb8MWjpjh7bYLB8eOpM-KTWiI=.fecd58fe-c77a-4c50-a620-0a5f1f0da37d@github.com>
References: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>
 <OeVc5dTShypEPycaa3Wb8MWjpjh7bYLB8eOpM-KTWiI=.fecd58fe-c77a-4c50-a620-0a5f1f0da37d@github.com>
Message-ID: <ODmprpUm5f1y03aTBBmT9j1WxlpLbPirxUnZ2owDQHM=.ec32bd6f-3b18-430a-a670-11a7e89ecbcc@github.com>

On Wed, 30 Sep 2020 07:47:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are lots of Shenandoah-related test failures in current runs, triggered by new assert in JDK-8212107. The assert
>> looks legitimate, and Shenandoah code should instead be more relaxed here, by checking it runs in VMThread before
>> accessing its state.  Testing:
>>   - [x] hotspot_gc_shenandoah
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the not very valid change

Looks good to me.

Thanks for fixing it.

-------------

Marked as reviewed by jiefu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/424

From rehn at openjdk.java.net  Wed Sep 30 08:33:19 2020
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 30 Sep 2020 08:33:19 GMT
Subject: RFR: 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint
 should not access VMThread state from other threads [v2]
In-Reply-To: <OeVc5dTShypEPycaa3Wb8MWjpjh7bYLB8eOpM-KTWiI=.fecd58fe-c77a-4c50-a620-0a5f1f0da37d@github.com>
References: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>
 <OeVc5dTShypEPycaa3Wb8MWjpjh7bYLB8eOpM-KTWiI=.fecd58fe-c77a-4c50-a620-0a5f1f0da37d@github.com>
Message-ID: <jsYS9eh9fJDXMLZuqziO_0HBEFs7bzw6FzQbLa_nDIE=.2e98f44f-0265-45ad-8cc6-14a674db1566@github.com>

On Wed, 30 Sep 2020 07:47:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are lots of Shenandoah-related test failures in current runs, triggered by new assert in JDK-8212107. The assert
>> looks legitimate, and Shenandoah code should instead be more relaxed here, by checking it runs in VMThread before
>> accessing its state.  Testing:
>>   - [x] hotspot_gc_shenandoah
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the not very valid change

Not sure what it's worth, but seems reasonable to me.

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/424

From rkennke at openjdk.java.net  Wed Sep 30 08:58:25 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 30 Sep 2020 08:58:25 GMT
Subject: RFR: 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint
 should not access VMThread state from other threads [v2]
In-Reply-To: <OeVc5dTShypEPycaa3Wb8MWjpjh7bYLB8eOpM-KTWiI=.fecd58fe-c77a-4c50-a620-0a5f1f0da37d@github.com>
References: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>
 <OeVc5dTShypEPycaa3Wb8MWjpjh7bYLB8eOpM-KTWiI=.fecd58fe-c77a-4c50-a620-0a5f1f0da37d@github.com>
Message-ID: <2CXAx_ftjKDd3xJl2w1BftL4pj660ryoGbZrNk0RvoE=.0bc4459e-bbf5-49fd-943e-2b3614ad015b@github.com>

On Wed, 30 Sep 2020 07:47:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are lots of Shenandoah-related test failures in current runs, triggered by new assert in JDK-8212107. The assert
>> looks legitimate, and Shenandoah code should instead be more relaxed here, by checking it runs in VMThread before
>> accessing its state.  Testing:
>>   - [x] hotspot_gc_shenandoah
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the not very valid change

Marked as reviewed by rkennke (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/424

From shade at openjdk.java.net  Wed Sep 30 09:01:16 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Sep 2020 09:01:16 GMT
Subject: Integrated: 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint
 should not access VMThread state from other threads
In-Reply-To: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>
References: <Ykr0o6S96GXRfMrjkY8KtrJtM8SEnweFo9fbo81sLXs=.4ed669e3-9e55-49b8-bf22-88aa995553f6@github.com>
Message-ID: <YOZmQkU4u92bj0KFjOO0-5oVLJ69Oc-1vsGqYADwPYY=.0d7d6d12-ad52-4b5e-9cdb-a1fd25aa5195@github.com>

On Wed, 30 Sep 2020 07:22:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are lots of Shenandoah-related test failures in current runs, triggered by new assert in JDK-8212107. The assert
> looks legitimate, and Shenandoah code should instead be more relaxed here, by checking it runs in VMThread before
> accessing its state.  Testing:
>   - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 8331e63f
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8331e63f
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint should not access VMThread state from other threads

Reviewed-by: jiefu, rehn, rkennke

-------------

PR: https://git.openjdk.java.net/jdk/pull/424

From kim.barrett at oracle.com  Wed Sep 30 15:40:15 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 30 Sep 2020 11:40:15 -0400
Subject: RFR: 8247912: Make narrowOop a scoped enum [v2]
In-Reply-To: <m1gL9hpAgwkYxxGMXVd2yCCqaUDgxd1JyQHc5UPIl9o=.f3ea6ced-4842-4aa8-afe1-0b03e9148105@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <m0g-MQZhsZfW_ZEabKcF54nEPiQ2IF-2Y6uRB_bug_Y=.4b48bcc0-bfa4-48b8-b9b6-8ce6680e454e@github.com>
 <m1gL9hpAgwkYxxGMXVd2yCCqaUDgxd1JyQHc5UPIl9o=.f3ea6ced-4842-4aa8-afe1-0b03e9148105@github.com>
Message-ID: <3637E30D-FCBC-4901-ACCE-6C86110C6708@oracle.com>

> On Sep 29, 2020, at 8:42 AM, Stefan Karlsson <stefank at openjdk.java.net> wrote:
> 
> On Tue, 22 Sep 2020 13:43:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> 
>>> Please review this change to the type narrowOop from a typedef for juint to a
>>> scoped enum with uint32_t as the representation type.  This provides stronger
>>> type checking when using this type.
>>> 
>>> For the most part this was fairly straightforward, and the patch size is
>>> relatively small.  The implementation of some existing CompressedOops
>>> "primitives" required adjustment. An explicit conversion to narrowOop was
>>> added, with casts change to use it.  There were a few places that were type
>>> punning and needed explicit conversions,, mostly in platform-specific assembly
>>> support.
>>> 
>>> There are a couple of lingering problems.
>>> 
>>> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
>>> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
>>> this probably ought to be done differently.
>>> 
>>> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
>>> whether these can be safely converted to CompressedOops::narrow_oop_cast.
>>> 
>>> There might still be some casts from narrowOop to an integral type.  Those are
>>> hard to find in our cast-happy code base.
>>> 
>>> Testing:
>>> tier1-6 for Oracle supported platforms.
>>> Build fastdebug linux-ppc64le and linux-s390x.
>> 
>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>> - improve assertion
>> - remove NarrowType
> 
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179:
> 
>> 177:     // Move narrow OOP
>> 178:     narrowOop noop = CompressedOops::encode((oop)o);
>> 179:     uint32_t n = CompressedOops::narrow_oop_value(noop);
> 
> I wonder if we should simply create an overload for oop so that this (and the other places) could be changed to:
> n = CompressedOops::narrow_oop_value((oop)o);```

Nice idea. Will be in next PR update.

> src/hotspot/cpu/ppc/relocInfo_ppc.cpp line 62:
> 
>> 60:       narrowOop no = (type() == relocInfo::oop_type) ?
>> 61:           CompressedOops::encode((oop)x) :
>> 62:           // FIXME: Cheating! Treating narrowKlass as a narrowOop.
> 
> I think we try to avoid adding new FIXMES and TODOS to the code. Maybe create a JBS entry instead?

Oops, forgot about that.  I?ve changed the comment to just note the type pun, and filed
https://bugs.openjdk.java.net/browse/JDK-8253860

> PR: https://git.openjdk.java.net/jdk/pull/273



From kbarrett at openjdk.java.net  Wed Sep 30 18:35:00 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 30 Sep 2020 18:35:00 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v3]
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <U_bJqWzYmT5O7LWZplb1645nUqbWtz_Q1LrA-vfSndw=.20d5de77-0832-4619-ac08-19a17f98bd79@github.com>

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  stefank review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/273/files
  - new: https://git.openjdk.java.net/jdk/pull/273/files/e36f7895..0fba2ef1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=01-02

  Stats: 39 lines in 8 files changed: 17 ins; 12 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273

PR: https://git.openjdk.java.net/jdk/pull/273

From kbarrett at openjdk.java.net  Wed Sep 30 18:45:10 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 30 Sep 2020 18:45:10 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v4]
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <DCgcwy47Cgk-gv32zoCr1N3DG8o7IuGNW3_cRpcKOaE=.328a4c49-c538-4b0b-b9dc-ca515b7671ea@github.com>

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  add missing inlines for consistency

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/273/files
  - new: https://git.openjdk.java.net/jdk/pull/273/files/0fba2ef1..38d0088f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273

PR: https://git.openjdk.java.net/jdk/pull/273

From kbarrett at openjdk.java.net  Wed Sep 30 18:50:46 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 30 Sep 2020 18:50:46 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v5]
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <gt_FQyVtfiAf6vC0hiVfPpzCqbNK-7a4tgzGhthD1pM=.7a858b7b-eff3-49ad-a1b2-c38b9d0ff380@github.com>

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since
the last revision:

 - Merge branch 'master' into strong_narrowoop
 - add missing inlines for consistency
 - stefank review
 - improve assertion
 - remove NarrowType
 - 8247912: Make narrowOop a scoped enum

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/273/files
  - new: https://git.openjdk.java.net/jdk/pull/273/files/38d0088f..f6b93d4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=03-04

  Stats: 41108 lines in 2221 files changed: 9689 ins; 25600 del; 5819 mod
  Patch: https://git.openjdk.java.net/jdk/pull/273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273

PR: https://git.openjdk.java.net/jdk/pull/273

From zgu at openjdk.java.net  Wed Sep 30 19:03:38 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 30 Sep 2020 19:03:38 GMT
Subject: RFR: 8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler related
 code
Message-ID: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>

There are a couple of bugs in ShenandoahEvacOOMHandler related code.

1) ShenandoahEvacOOMHandler::register_thread()
It does not do OOM check before blindly cmpxchg in threads_in_evac. The cmpxchg can success even OOM is in progress,
that results the thread to continue evacuate objects.

2) When a nested OOM scope encounters OOM, it does not decrease threads_in_evac count before entering
wait_for_no_evac_threads() loop, it deadlocks itself.

-------------

Commit messages:
 - 8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler related code

Changes: https://git.openjdk.java.net/jdk/pull/439/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=439&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253857
  Stats: 26 lines in 2 files changed: 8 ins; 7 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/439.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/439/head:pull/439

PR: https://git.openjdk.java.net/jdk/pull/439

From github.com+51754783+CoreyAshford at openjdk.java.net  Wed Sep 30 19:19:24 2020
From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford)
Date: Wed, 30 Sep 2020 19:19:24 GMT
Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
 <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
Message-ID: <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>

On Tue, 29 Sep 2020 16:39:25 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> Did you try on x86? AOT is not supported on PPC64.

After looking at this a bit, I find that there seems to be an assumption in the code that if there is an intrinsic
symbol defined in aotCodeHeap.cpp using the SET_AOT_GLOBAL_SYMBOL_VALUE macro, it is required that the intrinsic is
implemented for every arch that implements AOT.  In this case, there isn't an implementation for x86_64 (yet), so
that's why the failure is occurring.

I was tempted to put in an arch-specific #if for ppc arch only, but I don't see any arch-specific code in this area,
and it doesn't make sense either because AOT isn't supported on ppc at all.  Another alternative is to remove the
SET_AOT_GLOBAL_SYMBOL_VALUE for decodeBlock, since the implementation is not defined (yet) for any arch which supports
AOT.

A third alternative would be to leave the macro call in, but comment it out, saying to uncomment it when it's supported
on all AOT-capable arches.

Any thoughts?

-------------

PR: https://git.openjdk.java.net/jdk/pull/293