RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Ludovic Henry]

It’s me who made a mistake. This PR should be associated with JEP 388 as you 
are rightly pointing out.

From: Daniel D. Daugherty 
Sent: Thursday, October 1, 2020 3:05 PM
To: Ludovic Henry ; David Holmes 
; David Holmes ; Andrew 
Haley ; Chris Plummer ; 
Magnus Ihse Bursie ; build-dev@openjdk.java.net; 
core-libs-...@openjdk.java.net; hotspot-...@openjdk.java.net; 
serviceability-...@openjdk.java.net; shenandoah-...@openjdk.java.net; Monica 
Beckwith 
Subject: Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

So I'm confused... this PR is associated with this bug ID:


Issue

  *   
JDK-8248238<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353=FV0tr%2FktSPQDxHkI1JMr7UCgW4ygPi8d4yKsGuPVUg8%3D=0>:
 Implementation of JEP: Windows AArch64 Support


and JDK-8248238 is associated with this JEP:


JDK-8248496<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248496=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353=HAjFLX%2BtIaKz%2FFULuav%2BUXn6qTZb%2BkjiS4ijsWw7RQE%3D=0>
 JEP 388: Windows/AArch64 Port

Am I missing something here?

Dan

On 10/1/20 5:56 PM, Ludovic Henry wrote:

Hi David,



The JEP is not yet targeted so we have to wait for that formality. But once 
that happens I can sponsor for you.



Perfect, I didn't know about the need for the JEP to be targeted before the 
merge.



Also note that the PR references the wrong JEP so can you please edit the 
description to fix that.



I'll work with @Monica to update the PR's description to point to 
https://openjdk.java.net/jeps/391<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F391=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436464348=Pj%2FNQvzEa8mrhvY75OFVBG7k623Mgnr56Xo3On%2BoQGo%3D=0>
 instead.



Thank you!

Ludovic

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Daniel D. Daugherty]

So I'm confused... this PR is associated with this bug ID:



  Issue

  * JDK-8248238 :
Implementation of JEP: Windows AArch64 Support




and JDK-8248238 is associated with this JEP:

JDK-8248496  JEP 
388: Windows/AArch64 Port 


Am I missing something here?

Dan


On 10/1/20 5:56 PM, Ludovic Henry wrote:

Hi David,


The JEP is not yet targeted so we have to wait for that formality. But once 
that happens I can sponsor for you.

Perfect, I didn't know about the need for the JEP to be targeted before the 
merge.


Also note that the PR references the wrong JEP so can you please edit the 
description to fix that.

I'll work with @Monica to update the PR's description to point to 
https://openjdk.java.net/jeps/391 instead.

Thank you!
Ludovic
  

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[David Holmes]

Hi,

On 2/10/2020 1:48 am, Ludovic Henry wrote:

Hi,

As we now have a whole bunch of reviews (thank you all!), we would need a 
sponsor to get it merged.


The JEP is not yet targeted so we have to wait for that formality. But 
once that happens I can sponsor for you.


Also note that the PR references the wrong JEP so can you please edit 
the description to fix that.


Meanwhile I'll see if I can take this for a spin through our internal 
testing.


Cheers,
David
-


Thank you :)

-

PR: https://github.com/openjdk/jdk/pull/212

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Ludovic Henry]

Hi David,

> The JEP is not yet targeted so we have to wait for that formality. But once 
> that happens I can sponsor for you.

Perfect, I didn't know about the need for the JEP to be targeted before the 
merge.

> Also note that the PR references the wrong JEP so can you please edit the 
> description to fix that.

I'll work with @Monica to update the PR's description to point to 
https://openjdk.java.net/jeps/391 instead.

Thank you!
Ludovic
 

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Ludovic Henry]

Hi,

As we now have a whole bunch of reviews (thank you all!), we would need a 
sponsor to get it merged.

Thank you :) 

-

PR: https://github.com/openjdk/jdk/pull/212

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[David Holmes]

On Tue, 29 Sep 2020 14:08:49 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Chris Plummer]

On Tue, 29 Sep 2020 14:08:49 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]

[Chris Plummer]

On Tue, 29 Sep 2020 14:03:57 GMT, Bernhard Urban-Forster  
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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Monica Beckwith]

> 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=212=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]

[Bernhard Urban-Forster]

On Fri, 25 Sep 2020 12:44:37 GMT, Andrew Haley  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11]

[Magnus Ihse Bursie]

On Mon, 28 Sep 2020 19:53:37 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Andrew Haley]

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://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Andrew Haley]

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://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11]

[David Holmes]

On Mon, 28 Sep 2020 19:53:37 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11]

[Monica Beckwith]

> 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=212=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Vladimir Kempik]

On Mon, 28 Sep 2020 19:38:15 GMT, Bernhard Urban-Forster  
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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Bernhard Urban-Forster]

On Mon, 28 Sep 2020 19:28:10 GMT, Vladimir Kempik  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Vladimir Kempik]

On Mon, 28 Sep 2020 19:09:17 GMT, Bernhard Urban-Forster  
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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Bernhard Urban-Forster]

On Mon, 28 Sep 2020 17:37:32 GMT, Vladimir Kempik  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Vladimir Kempik]

On Mon, 28 Sep 2020 14:07:16 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Monica Beckwith]

> 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=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v9]

[Monica Beckwith]

> 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=212=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

[Bernhard Urban-Forster]

On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v8]

[Monica Beckwith]

> 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=212=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]

[Andrew Haley]

On Thu, 24 Sep 2020 15:15:45 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

[David Holmes]

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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

[Monica Beckwith]

On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

[Chris Plummer]

On Thu, 24 Sep 2020 14:04:22 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

[Bernhard Urban-Forster]

On Thu, 24 Sep 2020 04:52:22 GMT, David Holmes  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]

[Monica Beckwith]

> 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=212=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

[Bernhard Urban-Forster]

On Thu, 24 Sep 2020 04:45:16 GMT, David Holmes  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

[Monica Beckwith]

> 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=212=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

[David Holmes]

On Thu, 24 Sep 2020 04:57:39 GMT, David Holmes  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

[David Holmes]

On Wed, 23 Sep 2020 13:23:43 GMT, 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]
>> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

[Monica Beckwith]

> 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=212=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

[Monica Beckwith]

On Mon, 21 Sep 2020 14:47:15 GMT, Bernhard Urban-Forster  
wrote:

>>> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on 
>>> [build-dev](mailto:build-dev@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:a...@redhat.com) on 
>> [build-dev](mailto:build-dev@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:a...@redhat.com) on 
> [build-dev](mailto:build-dev@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://keybase.io/andrewhaley
> 

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]

[Erik Joelsson]

On Mon, 21 Sep 2020 07:10:47 GMT, Bernhard Urban-Forster  
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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]

[Bernhard Urban-Forster]

On Mon, 21 Sep 2020 08:15:20 GMT, Bernhard Urban-Forster  
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:a...@redhat.com) on 
>> [build-dev](mailto:build-dev@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:a...@redhat.com) on 
> [build-dev](mailto:build-dev@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:  
> > 

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]

[Monica Beckwith]

> 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=212=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

[Andrew Haley]

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://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

[Bernhard Urban-Forster]

On Fri, 18 Sep 2020 18:38:34 GMT, Bernhard Urban-Forster  
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:a...@redhat.com) on 
> [build-dev](mailto:build-dev@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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

[Monica Beckwith]

> 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=212=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2]

[Bernhard Urban-Forster]

On Fri, 18 Sep 2020 20:34:55 GMT, Erik Joelsson  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Andrew Haley]

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://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
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]"],

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Andrew Haley]

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://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Erik Joelsson]

On Wed, 16 Sep 2020 20:26:10 GMT, 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]
> * 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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Erik Joelsson]

On Fri, 18 Sep 2020 20:32:36 GMT, Erik Joelsson  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Bernhard Urban-Forster]

On Fri, 18 Sep 2020 15:34:26 GMT, Erik Joelsson  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Erik Joelsson]

On Fri, 18 Sep 2020 13:33:07 GMT, Erik Joelsson  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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Erik Joelsson]

On Wed, 16 Sep 2020 20:26:10 GMT, 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]
> * 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

RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Monica Beckwith]

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=212=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