Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8248238: Implementation: JEP 388: Windows AArch64 Support #301

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

@rnkovacs
Copy link
Contributor

@rnkovacs rnkovacs commented Aug 30, 2021

Main commit of the Windows/AArch64 port.

Also fixes JDK-8272181 by adding src/hotspot/os_cpu/windows_aarch64/pauth_windows_aarch64.inline.hpp, which is needed for a successful Windows-AArch64 build.

Depends on #274 and #299.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issues

  • JDK-8248238: Implementation: JEP 388: Windows AArch64 Support
  • JDK-8272181: Windows-AArch64:Backport fix of Backtracing broken on PAC enabled systems

Reviewers

Contributors

  • Monica Beckwith <mbeckwit@openjdk.org>
  • Ludovic Henry <luhenry@openjdk.org>
  • Bernhard Urban-Forster <burban@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk11u-dev pull/301/head:pull/301
$ git checkout pull/301

Update a local copy of the PR:
$ git checkout pull/301
$ git pull https://git.openjdk.java.net/jdk11u-dev pull/301/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 301

View PR using the GUI difftool:
$ git pr show -t 301

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk11u-dev/pull/301.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Aug 30, 2021

👋 Welcome back rnkovacs! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot changed the title Backport 9604ee82690f89320614b37bfef4178abc869777 8248238: Implementation: JEP 388: Windows AArch64 Support Aug 30, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Aug 30, 2021

This backport pull request has now been updated with issue from the original commit.

@openjdk openjdk bot added the backport label Aug 30, 2021
@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Aug 30, 2021

/contributor add Monica Beckwith mbeckwit@openjdk.org
/contributor add Ludovic Henry luhenry@openjdk.org
/contributor add Bernhard Urban-Forster burban@openjdk.org

@openjdk
Copy link

@openjdk openjdk bot commented Aug 30, 2021

@rnkovacs
Contributor Monica Beckwith <mbeckwit@openjdk.org> successfully added.

@openjdk
Copy link

@openjdk openjdk bot commented Aug 30, 2021

@rnkovacs
Contributor Ludovic Henry <luhenry@openjdk.org> successfully added.

@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Aug 30, 2021

/issue add 8272181

@openjdk
Copy link

@openjdk openjdk bot commented Aug 30, 2021

@rnkovacs
Contributor Bernhard Urban-Forster <burban@openjdk.org> successfully added.

@openjdk
Copy link

@openjdk openjdk bot commented Aug 30, 2021

@rnkovacs
Adding additional issue to issue list: 8272181: Windows-AArch64:Backport fix of Backtracing broken on PAC enabled systems``.

@rnkovacs rnkovacs force-pushed the 8248238-win-aarch64 branch from 931f39e to 4f530dd Aug 30, 2021
@rnkovacs rnkovacs marked this pull request as ready for review Aug 30, 2021
@openjdk openjdk bot added the rfr label Aug 30, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Aug 30, 2021

@RealCLanger
Copy link
Contributor

@RealCLanger RealCLanger commented Aug 30, 2021

Hi @rnkovacs, can you split these into separate, dependent Pull requests?
E.g. #274 as first in the row. Then, open another PR in favor of #299 that has branch pr/274 as target. And then the 3 commits included in this one also as separate PRs, targeting the appropriate predecessor PR?

@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Aug 30, 2021

Hi @RealCLanger, I attempted to do that but apparently failed - I forgot to change the target branch. Do I need to close #299 and this one and open completely new PRs?

@rnkovacs rnkovacs changed the base branch from master to pr/299 Aug 30, 2021
@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Aug 30, 2021

Seems like I could do the change on the GUI. Could you please check if it's correct now?

@RealCLanger
Copy link
Contributor

@RealCLanger RealCLanger commented Aug 30, 2021

Seems like I could do the change on the GUI. Could you please check if it's correct now?

Yes, I think this looks good now, thanks.

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Sep 2, 2021

One question, about R18 exclusion part.
In the light of recent issues with r18 being finally used by OS for its own needs ( since macos12b6), I have made some tests. ( more about issues here https://youtrack.jetbrains.com/issue/JBR-3715)
I took part of this PR which belongs to R18 usage elimination and applied it to zulu11 ( reverting older version of patch first which wasn't working with C2 compiled code)
This fixed zulu11 under macos12b6 and I was happy about that.
However I have noticed one strange thing
I did this:
bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -jar demo/jfc/J2Ddemo/J2Ddemo.jar > output.log
then this:
cat output.log | grep x18 | grep -v 0x18
and found some usage of x18:
0x000000010bcafc80: stp x18, x19, [sp, #144]
0x000000010bcb0b60: stp x18, x19, [sp, #144]
0x000000010bcb1590: stp x18, x19, [sp, #144]
0x000000010bcb2470: stp x18, x19, [sp, #144]
0x000000010bcb3dd0: stp x18, x19, [sp, #144]
0x000000010bcb4cd0: stp x18, x19, [sp, #144]
0x000000010bcb5ae0: stp x18, x19, [sp, #144]

it's just reading of x18, not writing, however it might indicate something is still missing there.
this doesn't happen on jdk17ea

Could you try to replicate this result with win-arm64 build of jdk11 ( make sure to put hsdis in there)

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Sep 2, 2021

An example, it's always in Stub Code
[Exception Handler]
[Stub Code]
0x0000000109fe4340: adrp x8, 0x0000000109b39000
; {no_reloc}
0x0000000109fe4344: add x8, x8, #0x580
0x0000000109fe4348: blr x8
0x0000000109fe434c: stp x0, x1, [sp, #-256]!
0x0000000109fe4350: stp x2, x3, [sp, #16]
0x0000000109fe4354: stp x4, x5, [sp, #32]
0x0000000109fe4358: stp x6, x7, [sp, #48]
0x0000000109fe435c: stp x8, x9, [sp, #64]
0x0000000109fe4360: stp x10, x11, [sp, #80]
0x0000000109fe4364: stp x12, x13, [sp, #96]
0x0000000109fe4368: stp x14, x15, [sp, #112]
0x0000000109fe436c: stp x16, x17, [sp, #128]
0x0000000109fe4370: stp x18, x19, [sp, #144]
0x0000000109fe4374: stp x20, x21, [sp, #160]
0x0000000109fe4378: stp x22, x23, [sp, #176]
0x0000000109fe437c: stp x24, x25, [sp, #192]
0x0000000109fe4380: stp x26, x27, [sp, #208]

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Sep 2, 2021

So it's
void MacroAssembler::stop(const char* msg) {
address ip = pc();
pusha();
movptr(c_rarg0, (uintptr_t)(address)msg);
movptr(c_rarg1, (uintptr_t)(address)ip);
mov(c_rarg2, sp);
mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64));
blr(c_rarg3);
hlt(0);
}
where pusha is :

void MacroAssembler::pusha() {
push(0x7fffffff, sp);
}

where push is:

// Push lots of registers in the bit set supplied. Don't push sp.
// Return the number of words pushed
int MacroAssembler::push(unsigned int bitset, Register stack) {
int words_pushed = 0;

// Scan bitset to accumulate register pairs
unsigned char regs[32];
int count = 0;
for (int reg = 0; reg <= 30; reg++) {
if (1 & bitset)
regs[count++] = reg;
bitset >>= 1;
}
...

@theRealAph could you please suggest, do we need to change the mask in pusha for win-arm64/mac-arm64 to not save r18 by pusha ?

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Sep 7, 2021

Yes, exartly.

It could be:

push(RegSet::range(r0, r29) R18_RESERVED_ONLY(-r18_tls), sp);

Copy link

@VladimirKempik VladimirKempik left a comment

Yes, exartly.

It could be:

push(RegSet::range(r0, r29) R18_RESERVED_ONLY(-r18_tls), sp);

But it should probably be done here
https://github.com/openjdk/jdk11u-dev/pull/301/files#diff-0f4150a9c607ccd590bf256daa800c0276144682a92bc6bdced5e8bc1bb81f3aR2548

ah, you were probably talking about pusha(), I initially thought it was about call_clobbered_registers()

void MacroAssembler::push_call_clobbered_registers() {
int step = 4 * wordSize;
push(RegSet::range(r0, r18) - RegSet::of(rscratch1, rscratch2), sp);
push(call_clobbered_registers() - RegSet::of(rscratch1, rscratch2), sp);

is it right to substract rscratch1/2 twice, fist in call_clobbered_registers, then here ?

Copy link
Contributor

@theRealAph theRealAph Sep 8, 2021

It's not exactly wrong. The readability of the code seems to have suffered in translation.

Copy link
Contributor

@theRealAph theRealAph Sep 8, 2021

Looking at the actual change make to development head, this is a misapplied patch. To match head, this should be:

RegSet MacroAssembler::call_clobbered_registers() {
  RegSet regs = RegSet::range(r0, r17) - RegSet::of(rscratch1, rscratch2);
#ifndef R18_RESERVED
  regs += r18_tls;
#endif
  return regs;
}
void MacroAssembler::push_call_clobbered_registers() {
  int step = 4 * wordSize;
  push(call_clobbered_registers(), sp);

Strictly speaking it should also push rscratch1 and rscratch2 - they are call clobbered - but we don't care because any macro can trash rscratch1 and rscratch2, so there's no point saving and restoring them.

Copy link
Contributor Author

@rnkovacs rnkovacs Oct 4, 2021

Thanks for catching this @VladimirKempik.

Copy link
Contributor Author

@rnkovacs rnkovacs Oct 4, 2021

@theRealAph you're right about push_call_clobbered_registers(), but I think call_clobbered_registers() is actually fine the way it is. The register named r18_tls on tip has been renamed to r18_reserved in this backport.

Copy link
Contributor

@theRealAph theRealAph Oct 6, 2021

Looks to me like the only real issue here is warn(). stop() doesn't restore the registers, so that's fine. We do want to see all the registers in a register dump. It would be better if pusha() were left as it is, but popa() did not clobber r18.

Copy link
Contributor Author

@rnkovacs rnkovacs Oct 14, 2021

I believe this concern is addressed by openjdk/jdk#5828. Are you okay with leaving this patch as-is and backporting that soon after?

Copy link
Contributor

@theRealAph theRealAph Oct 15, 2021

The register named r18_tls on tip has been renamed to r18_reserved in this backport.

Why has it been renamed r18_reserved ?

Copy link
Contributor Author

@rnkovacs rnkovacs Oct 15, 2021

Turns out I was missing some history & context on this - it was r18_reserved originally, but there was a partial rewrite to r18_tls that I finished in the wrong direction. @lewurm's testing the fix, then I'll update.

@lewurm
Copy link
Member

@lewurm lewurm commented Oct 1, 2021

[...] where pusha is :

void MacroAssembler::pusha() { push(0x7fffffff, sp); }

[...]

Nice catch!

I'm not sure if this should go as part of this PR. The same problem exists in jdk-tip and therefore should be addressed there first:
https://github.com/openjdk/jdk/blob/c05dc268acaf87236f30cf700ea3ac778e3b20e5/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L1859-L1865

On jdk-tip there is only one usage left in the template interpreter generator: https://github.com/openjdk/jdk/blob/c05dc268acaf87236f30cf700ea3ac778e3b20e5/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1400-L1404

Seems like the code path is uncommon, but we should still fix it imho.

What do you think?

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Oct 2, 2021

Since this PR is kind of stuck, can we get R18 patch out of it and push it under separate PR ? this will make macos-aarch64 port not dependent on win-aarch64 anymore

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Oct 3, 2021

To unbreak things, somebody would need to review #274 as a first step.

Done.

@RealCLanger
Copy link
Contributor

@RealCLanger RealCLanger commented Oct 3, 2021

To unbreak things, somebody would need to review #274 as a first step.

Done.

Thanks. Maybe you could also look at #300 as I believe those two should go together. Still it's mostly about Windows.

@lewurm
Copy link
Member

@lewurm lewurm commented Oct 4, 2021

Since this PR is kind of stuck, can we get R18 patch out of it and push it under separate PR ? this will make macos-aarch64 port not dependent on win-aarch64 anymore

OK.

Please let's not go there, it would delay this PR much further. I think we are close to the finish line.

Those PRs must go in the following order:

  1. #274
  2. #299

Then this JEP PR is ready to be merged.

@rnkovacs rnkovacs force-pushed the 8248238-win-aarch64 branch from f7f50ab to 142c38d Oct 4, 2021
@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Oct 4, 2021

Rebased on top of updated dependencies and removed redundant subtraction of scratch registers in MacroAssembler::push_call_clobbered_registers().

I didn't do the pusha() part yet as I haven't seen any response to @lewurm's suggestion:

[...] where pusha is :
void MacroAssembler::pusha() { push(0x7fffffff, sp); }
[...]

Nice catch!

I'm not sure if this should go as part of this PR. The same problem exists in jdk-tip and therefore should be addressed there first: https://github.com/openjdk/jdk/blob/c05dc268acaf87236f30cf700ea3ac778e3b20e5/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L1859-L1865

On jdk-tip there is only one usage left in the template interpreter generator: https://github.com/openjdk/jdk/blob/c05dc268acaf87236f30cf700ea3ac778e3b20e5/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1400-L1404

Seems like the code path is uncommon, but we should still fix it imho.

What do you think?

@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Oct 4, 2021

To unbreak things, somebody would need to review #274 as a first step.

Done.

Thanks. Maybe you could also look at #300 as I believe those two should go together. Still it's mostly about Windows.

Thank you @theRealAph!

Actually, the connection between #274 and #300 is administrative in nature (originally, refactorings of 3 different areas were reviewed under the same JBS bug), there's no real dependency. It doesn't have to delay this stack of patches.

@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Oct 4, 2021

@RealCLanger responding to your comment under #222, the remaining PRs:

These 3 need to go in in this order:

  1. #274
  2. #299
  3. #301 (this one)

These two depend on #301:

  • #304 (accepted, ready to be integrated)
  • #307 (rebased, waiting for review)

These two could go in independently:

  • #300 (accepted but debated)
  • #280 (ongoing review)

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Oct 5, 2021

[...] where pusha is :
void MacroAssembler::pusha() { push(0x7fffffff, sp); }
[...]

Nice catch!

I'm not sure if this should go as part of this PR. The same problem exists in jdk-tip and therefore should be addressed there first: https://github.com/openjdk/jdk/blob/c05dc268acaf87236f30cf700ea3ac778e3b20e5/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L1859-L1865

On jdk-tip there is only one usage left in the template interpreter generator: https://github.com/openjdk/jdk/blob/c05dc268acaf87236f30cf700ea3ac778e3b20e5/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1400-L1404

Seems like the code path is uncommon, but we should still fix it imho.

What do you think?

I haven't spotted the usage of r18 ( saving r18 on stack) in jdk17 with hsdis, hence I was thinking it's not affected and the fix is needed only in jdk11

@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Oct 5, 2021

Rebase after the merge of #274.

@lewurm
Copy link
Member

@lewurm lewurm commented Oct 5, 2021

I haven't spotted the usage of r18 ( saving r18 on stack) in jdk17 with hsdis, hence I was thinking it's not affected and the fix is needed only in jdk11

I see it with -XX:+PrintInterpreter on tip (not jdk17, but close enough?). Therefore I submitted this PR: openjdk/jdk#5828

openjdk-notifier bot pushed a commit to openjdk/jdk that referenced this issue Oct 5, 2021
r18 should not be used as it is reserved as platform register. Linux is
fine with userspace using it, but Windows and also recently macOS (
openjdk/jdk11u-dev#301 (comment) )
are actually using it on the kernel side.

The macro assembler uses the bit pattern `0x7fffffff` (== `r0-r30`) to
specify which registers to spill; fortunately this helper is only used
here:
https://github.com/openjdk/jdk/blob/c05dc268acaf87236f30cf700ea3ac778e3b20e5/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1400-L1404

I haven't seen causing this particular instance any issues in practice
_yet_, presumably because it looks hard to align the stars in order to
trigger a problem (between stp and ldp of r18 a transition to kernel
space must happen *and* the kernel needs to do something with r18). But
jdk11u-dev has more usages of the `::pusha`/`::popa` macro and that
causes troubles as explained in the link above.

Output of `-XX:+PrintInterpreter` before this change:
```
----------------------------------------------------------------------
method entry point (kind = native)  [0x0000000138809b00, 0x000000013880a280]  1920 bytes
--------------------------------------------------------------------------------
  0x0000000138809b00:   ldr x2, [x12, #16]
  0x0000000138809b04:   ldrh    w2, [x2, #44]
  0x0000000138809b08:   add x24, x20, x2, uxtx #3
  0x0000000138809b0c:   sub x24, x24, #0x8
[...]
  0x0000000138809fa4:   stp x16, x17, [sp, #128]
  0x0000000138809fa8:   stp x18, x19, [sp, #144]
  0x0000000138809fac:   stp x20, x21, [sp, #160]
[...]
  0x0000000138809fc0:   stp x30, xzr, [sp, #240]
  0x0000000138809fc4:   mov x0, x28
 ;; 0x10864ACCC
  0x0000000138809fc8:   mov x9, #0xaccc                 // #44236
  0x0000000138809fcc:   movk    x9, #0x864, lsl #16
  0x0000000138809fd0:   movk    x9, #0x1, lsl #32
  0x0000000138809fd4:   blr x9
  0x0000000138809fd8:   ldp x2, x3, [sp, #16]
[...]
  0x0000000138809ff4:   ldp x16, x17, [sp, #128]
  0x0000000138809ff8:   ldp x18, x19, [sp, #144]
  0x0000000138809ffc:   ldp x20, x21, [sp, #160]
```

After:
```
----------------------------------------------------------------------
method entry point (kind = native)  [0x0000000108e4db00, 0x0000000108e4e280]  1920 bytes

--------------------------------------------------------------------------------
  0x0000000108e4db00:   ldr x2, [x12, #16]
  0x0000000108e4db04:   ldrh    w2, [x2, #44]
  0x0000000108e4db08:   add x24, x20, x2, uxtx #3
  0x0000000108e4db0c:   sub x24, x24, #0x8
[...]
  0x0000000108e4dfa4:   stp x16, x17, [sp, #128]
  0x0000000108e4dfa8:   stp x19, x20, [sp, #144]
  0x0000000108e4dfac:   stp x21, x22, [sp, #160]
[...]
  0x0000000108e4dfbc:   stp x29, x30, [sp, #224]
  0x0000000108e4dfc0:   mov x0, x28
 ;; 0x107E4A06C
  0x0000000108e4dfc4:   mov x9, #0xa06c                 // #41068
  0x0000000108e4dfc8:   movk    x9, #0x7e4, lsl #16
  0x0000000108e4dfcc:   movk    x9, #0x1, lsl #32
  0x0000000108e4dfd0:   blr x9
  0x0000000108e4dfd4:   ldp x2, x3, [sp, #16]
[...]
  0x0000000108e4dff0:   ldp x16, x17, [sp, #128]
  0x0000000108e4dff4:   ldp x19, x20, [sp, #144]
  0x0000000108e4dff8:   ldp x21, x22, [sp, #160]
[...]
```
@openjdk-notifier openjdk-notifier bot changed the base branch from pr/299 to master Oct 12, 2021
@openjdk-notifier
Copy link

@openjdk-notifier openjdk-notifier bot commented Oct 12, 2021

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout 8253015-aarch64-refactoring
git fetch https://git.openjdk.java.net/jdk11u-dev master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

@rnkovacs rnkovacs force-pushed the 8248238-win-aarch64 branch from bd1adc8 to 7ae8001 Oct 12, 2021
@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Oct 12, 2021

Rebase after the merge of #299.

lewurm
lewurm approved these changes Oct 14, 2021
Copy link
Member

@lewurm lewurm left a comment

Ready to be merged. Looks good to me (but I'm not a formal reviewer).

@mlbridge
Copy link

@mlbridge mlbridge bot commented Oct 15, 2021

Mailing list message from Vladimir Kempik on jdk-updates-dev:

That PR solves the issue with warn() and it?s ok to fix that issue in a separate PR

@mlbridge
Copy link

@mlbridge mlbridge bot commented Oct 15, 2021

Mailing list message from Vladimir Kempik on jdk-updates-dev:

On one side - we should be as close to original commit in jdk/jdk as possible
on another side - r18_tls sounds windows-aarch64 only, r18_reserved sounds more general ( works for both macos/win).

@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Oct 15, 2021

Mailing list message from Vladimir Kempik on jdk-updates-dev:

On one side - we should be as close to original commit in jdk/jdk as possible on another side - r18_tls sounds windows-aarch64 only, r18_reserved sounds more general ( works for both macos/win).

Thanks @VladimirKempik, that's the reason why I assumed r18_reserved was the newer one. Which one do you prefer @theRealAph?

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Oct 16, 2021

Mailing list message from Vladimir Kempik on jdk-updates-dev:
On one side - we should be as close to original commit in jdk/jdk as possible on another side - r18_tls sounds windows-aarch64 only, r18_reserved sounds more general ( works for both macos/win).

Thanks @VladimirKempik, that's the reason why I assumed r18_reserved was the newer one. Which one do you prefer @theRealAph?

r18_tls. It's not very important, but Idon't think the name is inaccurate: as far as I know both platforms use r18 for thread-local storage. It' could just have been r18_do_not_use.

@rnkovacs rnkovacs force-pushed the 8248238-win-aarch64 branch from 7ae8001 to 609ad26 Oct 19, 2021
@rnkovacs
Copy link
Contributor Author

@rnkovacs rnkovacs commented Oct 19, 2021

Changed the name back to r18_tls.

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Oct 19, 2021

Mailing list message from Vladimir Kempik on jdk-updates-dev:
On one side - we should be as close to original commit in jdk/jdk as possible on another side - r18_tls sounds windows-aarch64 only, r18_reserved sounds more general ( works for both macos/win).

Thanks @VladimirKempik, that's the reason why I assumed r18_reserved was the newer one. Which one do you prefer @theRealAph?

r18_tls. It's not very important, but Idon't think the name is inaccurate: as far as I know both platforms use r18 for thread-local storage. It' could just have been r18_do_not_use.

Oh well, AFAIK nobody outside Apple knows what it's used for. It's even possible to use R18 in your own app on macos11/12 ( except macos12b6 - https://youtrack.jetbrains.com/issue/JBR-3715 )
By mistake we left r18 available for C2 on zulu11/13/15 ( also JetBrains Runtime 11) and it was working fine on all macos versions except 12beta6.

@lewurm
Copy link
Member

@lewurm lewurm commented Oct 21, 2021

@theRealAph could you review this PR please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants