JDK-8274795: AArch64: avoid spilling and restoring r18 in macro assembler #5828

lewurm · 2021-10-05T20:33:31Z

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 0x7fff_ffff (== r0-r30) to specify which registers to spill; fortunately this helper is only used here:

jdk/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp

Lines 1400 to 1404 in c05dc26

    
           __ pusha(); // XXX only save smashed registers 
        
           __ mov(c_rarg0, rthread); 
        
           __ mov(rscratch2, CAST_FROM_FN_PTR(address, SharedRuntime::reguard_yellow_pages)); 
        
           __ blr(rscratch2); 
        
           __ popa(); // XXX only restore smashed registers

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]
[...]

Progress

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

Issue

JDK-8274795: AArch64: avoid spilling and restoring r18 in macro assembler

Reviewers

Andrew Haley (@theRealAph - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5828/head:pull/5828
$ git checkout pull/5828

Update a local copy of the PR:
$ git checkout pull/5828
$ git pull https://git.openjdk.java.net/jdk pull/5828/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5828

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5828.diff

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, openjdk#16] 0x0000000138809b04: ldrh w2, [x2, openjdk#44] 0x0000000138809b08: add x24, x20, x2, uxtx openjdk#3 0x0000000138809b0c: sub x24, x24, #0x8 [...] 0x0000000138809fa4: stp x16, x17, [sp, openjdk#128] 0x0000000138809fa8: stp x18, x19, [sp, openjdk#144] 0x0000000138809fac: stp x20, x21, [sp, openjdk#160] [...] 0x0000000138809fc0: stp x30, xzr, [sp, openjdk#240] 0x0000000138809fc4: mov x0, x28 ;; 0x10864ACCC 0x0000000138809fc8: mov x9, #0xaccc // #44236 0x0000000138809fcc: movk x9, #0x864, lsl openjdk#16 0x0000000138809fd0: movk x9, #0x1, lsl openjdk#32 0x0000000138809fd4: blr x9 0x0000000138809fd8: ldp x2, x3, [sp, openjdk#16] [...] 0x0000000138809ff4: ldp x16, x17, [sp, openjdk#128] 0x0000000138809ff8: ldp x18, x19, [sp, openjdk#144] 0x0000000138809ffc: ldp x20, x21, [sp, openjdk#160] ``` After: ``` ---------------------------------------------------------------------- method entry point (kind = native) [0x0000000108e4db00, 0x0000000108e4e280] 1920 bytes -------------------------------------------------------------------------------- 0x0000000108e4db00: ldr x2, [x12, openjdk#16] 0x0000000108e4db04: ldrh w2, [x2, openjdk#44] 0x0000000108e4db08: add x24, x20, x2, uxtx openjdk#3 0x0000000108e4db0c: sub x24, x24, #0x8 [...] 0x0000000108e4dfa4: stp x16, x17, [sp, openjdk#128] 0x0000000108e4dfa8: stp x19, x20, [sp, openjdk#144] 0x0000000108e4dfac: stp x21, x22, [sp, openjdk#160] [...] 0x0000000108e4dfbc: stp x29, x30, [sp, openjdk#224] 0x0000000108e4dfc0: mov x0, x28 ;; 0x107E4A06C 0x0000000108e4dfc4: mov x9, #0xa06c // #41068 0x0000000108e4dfc8: movk x9, #0x7e4, lsl openjdk#16 0x0000000108e4dfcc: movk x9, #0x1, lsl openjdk#32 0x0000000108e4dfd0: blr x9 0x0000000108e4dfd4: ldp x2, x3, [sp, openjdk#16] [...] 0x0000000108e4dff0: ldp x16, x17, [sp, openjdk#128] 0x0000000108e4dff4: ldp x19, x20, [sp, openjdk#144] 0x0000000108e4dff8: ldp x21, x22, [sp, openjdk#160] [...] ```

bridgekeeper · 2021-10-05T20:34:27Z

👋 Welcome back burban! 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 · 2021-10-05T20:36:47Z

@lewurm The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-10-05T20:41:24Z

Webrevs

VladimirKempik · 2021-10-06T06:10:50Z

Skip printing R18 in MacroAssembler::debug64() too
as the R18 is missing in regs array after this patch

theRealAph · 2021-10-06T08:00:49Z

Better to delete pusha() and popa(), and just use push_call_clobered_registers();

VladimirKempik · 2021-10-06T08:27:07Z

Better to delete pusha() and popa(), and just use push_call_clobered_registers();

is it possible then to predict what to print in debug64 call ?

theRealAph · 2021-10-06T08:42:32Z

Please leave register printing alone.
Do push r18.
Don't pop r18.
I suggest

pop(RegSet::range(r0, r17));
#ifdef(R18_RESERVED)
ldp(zr, r19, Address(__ post(sp, 2 * wordSize)));
pop(RegSet::range(r20, r30));
#else
pop(RegSet::range(r18, r30));
#endif

This is explicit, and doesn't touch anything unnecessarily.

lewurm · 2021-10-06T08:45:37Z

Skip printing R18 in MacroAssembler::debug64() too as the R18 is missing in regs array after this patch

it's not, right? This PR changes ::pusha(), but generate_verify_oop() uses ::push and defines its own regset:

jdk/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

Lines 599 to 610 in df125f6

    
               __ push(RegSet::range(r0, r29), sp); 
        
               // debug(char* msg, int64_t pc, int64_t regs[]) 
        
               __ mov(c_rarg0, rscratch1);      // pass address of error message 
        
               __ mov(c_rarg1, lr);             // pass return address 
        
               __ mov(c_rarg2, sp);             // pass address of regs on stack 
        
           #ifndef PRODUCT 
        
               assert(frame::arg_reg_save_area_bytes == 0, "not expecting frame reg save area"); 
        
           #endif 
        
               BLOCK_COMMENT("call MacroAssembler::debug"); 
        
               __ mov(rscratch1, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); 
        
               __ blr(rscratch1);

That said, I think ::debug64() shouldn't touch regs[30] and regs[31], but this is for another time.

Restore looks like this now: ``` 0x0000000106e4dfcc: movk x9, #0x5e4, lsl openjdk#16 0x0000000106e4dfd0: movk x9, #0x1, lsl openjdk#32 0x0000000106e4dfd4: blr x9 0x0000000106e4dfd8: ldp x2, x3, [sp, openjdk#16] 0x0000000106e4dfdc: ldp x4, x5, [sp, openjdk#32] 0x0000000106e4dfe0: ldp x6, x7, [sp, openjdk#48] 0x0000000106e4dfe4: ldp x8, x9, [sp, openjdk#64] 0x0000000106e4dfe8: ldp x10, x11, [sp, openjdk#80] 0x0000000106e4dfec: ldp x12, x13, [sp, openjdk#96] 0x0000000106e4dff0: ldp x14, x15, [sp, openjdk#112] 0x0000000106e4dff4: ldp x16, x17, [sp, openjdk#128] 0x0000000106e4dff8: ldp x0, x1, [sp], openjdk#144 0x0000000106e4dffc: ldp xzr, x19, [sp], openjdk#16 0x0000000106e4e000: ldp x22, x23, [sp, openjdk#16] 0x0000000106e4e004: ldp x24, x25, [sp, openjdk#32] 0x0000000106e4e008: ldp x26, x27, [sp, openjdk#48] 0x0000000106e4e00c: ldp x28, x29, [sp, openjdk#64] 0x0000000106e4e010: ldp x30, xzr, [sp, openjdk#80] 0x0000000106e4e014: ldp x20, x21, [sp], openjdk#96 0x0000000106e4e018: ldur x12, [x29, #-24] 0x0000000106e4e01c: ldr x22, [x12, openjdk#16] 0x0000000106e4e020: add x22, x22, #0x30 0x0000000106e4e024: ldr x8, [x28, openjdk#8] ```

lewurm · 2021-10-06T08:59:46Z

Thanks for the review Andrew.

Restore looks like this now:

     0x0000000106e4dfcc:   movk    x9, #0x5e4, lsl #16
     0x0000000106e4dfd0:   movk    x9, #0x1, lsl #32
     0x0000000106e4dfd4:   blr x9
     0x0000000106e4dfd8:   ldp x2, x3, [sp, #16]
     0x0000000106e4dfdc:   ldp x4, x5, [sp, #32]
     0x0000000106e4dfe0:   ldp x6, x7, [sp, #48]
     0x0000000106e4dfe4:   ldp x8, x9, [sp, #64]
     0x0000000106e4dfe8:   ldp x10, x11, [sp, #80]
     0x0000000106e4dfec:   ldp x12, x13, [sp, #96]
     0x0000000106e4dff0:   ldp x14, x15, [sp, #112]
     0x0000000106e4dff4:   ldp x16, x17, [sp, #128]
     0x0000000106e4dff8:   ldp x0, x1, [sp], #144
     0x0000000106e4dffc:   ldp xzr, x19, [sp], #16
     0x0000000106e4e000:   ldp x22, x23, [sp, #16]
     0x0000000106e4e004:   ldp x24, x25, [sp, #32]
     0x0000000106e4e008:   ldp x26, x27, [sp, #48]
     0x0000000106e4e00c:   ldp x28, x29, [sp, #64]
     0x0000000106e4e010:   ldp x30, xzr, [sp, #80]
     0x0000000106e4e014:   ldp x20, x21, [sp], #96
     0x0000000106e4e018:   ldur    x12, [x29, #-24]
     0x0000000106e4e01c:   ldr x22, [x12, #16]
     0x0000000106e4e020:   add x22, x22, #0x30
     0x0000000106e4e024:   ldr x8, [x28, #8]

theRealAph · 2021-10-06T09:26:35Z

Sorry, stupid mistake: the pop is done in reverse, of course!

Please try this (still untested) code.

#ifdef(R18_RESERVED)
pop(RegSet::range(r20, r30));
ldp(zr, r19, Address(__ post(sp, 2 * wordSize)));
#else
pop(RegSet::range(r18, r30));
#endif
pop(RegSet::range(r0, r17));

lewurm · 2021-10-06T13:41:36Z

Sorry, stupid mistake: the pop is done in reverse, of course!

hmm, I think it's fine. Checkout the full listing:

 0x0000000130009f80:   b.ne    0x000000013000a018  // b.any
  0x0000000130009f84:   stp x0, x1, [sp, #-256]!
  0x0000000130009f88:   stp x2, x3, [sp, #16]
  0x0000000130009f8c:   stp x4, x5, [sp, #32]
  0x0000000130009f90:   stp x6, x7, [sp, #48]
  0x0000000130009f94:   stp x8, x9, [sp, #64]
  0x0000000130009f98:   stp x10, x11, [sp, #80]
  0x0000000130009f9c:   stp x12, x13, [sp, #96]
  0x0000000130009fa0:   stp x14, x15, [sp, #112]
  0x0000000130009fa4:   stp x16, x17, [sp, #128]
  0x0000000130009fa8:   stp x18, x19, [sp, #144]
  0x0000000130009fac:   stp x20, x21, [sp, #160]
  0x0000000130009fb0:   stp x22, x23, [sp, #176]
  0x0000000130009fb4:   stp x24, x25, [sp, #192]
  0x0000000130009fb8:   stp x26, x27, [sp, #208]
  0x0000000130009fbc:   stp x28, x29, [sp, #224]
  0x0000000130009fc0:   stp x30, xzr, [sp, #240]
  0x0000000130009fc4:   mov x0, x28
 ;; 0x10564AC0C
  0x0000000130009fc8:   mov x9, #0xac0c                 // #44044
  0x0000000130009fcc:   movk    x9, #0x564, lsl #16
  0x0000000130009fd0:   movk    x9, #0x1, lsl #32
  0x0000000130009fd4:   blr x9
  0x0000000130009fd8:   ldp x2, x3, [sp, #16]
  0x0000000130009fdc:   ldp x4, x5, [sp, #32]
  0x0000000130009fe0:   ldp x6, x7, [sp, #48]
  0x0000000130009fe4:   ldp x8, x9, [sp, #64]
  0x0000000130009fe8:   ldp x10, x11, [sp, #80]
  0x0000000130009fec:   ldp x12, x13, [sp, #96]
  0x0000000130009ff0:   ldp x14, x15, [sp, #112]
  0x0000000130009ff4:   ldp x16, x17, [sp, #128]
  0x0000000130009ff8:   ldp x0, x1, [sp], #144
  0x0000000130009ffc:   ldp xzr, x19, [sp], #16
  0x000000013000a000:   ldp x22, x23, [sp, #16]
  0x000000013000a004:   ldp x24, x25, [sp, #32]
  0x000000013000a008:   ldp x26, x27, [sp, #48]
  0x000000013000a00c:   ldp x28, x29, [sp, #64]
  0x000000013000a010:   ldp x30, xzr, [sp, #80]
  0x000000013000a014:   ldp x20, x21, [sp], #96
  0x000000013000a018:   ldur    x12, [x29, #-24]
  0x000000013000a01c:   ldr x22, [x12, #16]
  0x000000013000a020:   add x22, x22, #0x30
  0x000000013000a024:   ldr x8, [x28, #8]

In terms of testing, it seems hard to trigger, so I forced the code path via:

diff --git a/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp b/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
index d069345b9c0..046c325faa7 100644
--- a/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
@@ -1392,11 +1392,14 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {

   {
     Label no_reguard;
+    Label skip_check;
+    __ b(skip_check);
     __ lea(rscratch1, Address(rthread, in_bytes(JavaThread::stack_guard_state_offset())));
     __ ldrw(rscratch1, Address(rscratch1));
     __ cmp(rscratch1, (u1)StackOverflow::stack_guard_yellow_reserved_disabled);
     __ br(Assembler::NE, no_reguard);

+    __ bind(skip_check);
     __ push(RegSet::range(r0, r30), sp);
     __ mov(c_rarg0, rthread);
     __ mov(rscratch2, CAST_FROM_FN_PTR(address, SharedRuntime::reguard_yellow_pages));

which crashes with your most recent suggestion btw, but it's fine with what's in this PR right now.

Any better suggestion on how to test it?

theRealAph · 2021-10-06T14:03:26Z

Sorry, stupid mistake: the pop is done in reverse, of course!

hmm, I think it's fine. Checkout the full listing:

Any better suggestion on how to test it?

You're right, it looks fine. It's a bit odd but it's really OK.

I'd check it simply by stopping at the start of the push, printing all registers, and stepping through.

theRealAph · 2021-10-07T08:50:15Z

So we have fixed the only use of popa() so that it does not clobber R18. That is good.
However, I think we've found another bug. reguard_yellow_pages() is a native function, so we should be saving floating-point registers too. It looks to me like this code should use push_call_clobbered_registers(). Then we'll have no use for pusha() in trunk, and your fix for popa() can go into 11u.

lewurm · 2021-10-12T13:06:37Z

Thanks for the suggestion @theRealAph. By looking through the code I discovered another buggy set of helpers, {push,pop}_CPU_state() which also messed with r18.

Does it look fine to you, or should the code around reguard_yellow_pages() rather use {push,pop}-call_clobbered_registers()?

theRealAph · 2021-10-13T07:21:23Z

Thanks for the suggestion @theRealAph. By looking through the code I discovered another buggy set of helpers, {push,pop}_CPU_state() which also messed with r18.

Sure, so we can do the same thing there, if we stil need it.

Does it look fine to you, or should the code around reguard_yellow_pages() rather use {push,pop}-call_clobbered_registers()?

Yes, very much so.

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp

Co-authored-by: Andrew Haley <aph-open@littlepinkcloud.com>

lewurm · 2021-10-13T09:03:10Z

Does it look fine to you, or should the code around reguard_yellow_pages() rather use {push,pop}-call_clobbered_registers()?

Yes, very much so.

done, thanks!

openjdk · 2021-10-13T09:12:51Z

@lewurm This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8274795: AArch64: avoid spilling and restoring r18 in macro assembler

Reviewed-by: aph

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 103 new commits pushed to the master branch:

dcf428c: 8275075: Remove unnecessary conversion to String in jdk.hotspot.agent
c3b75c6: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references
337b73a: 8274851: [PPC64] Port zgc to linux on ppc64le
cf82867: 8275049: [ZGC] missing null check in ZNMethod::log_register
ab34cce: 8275186: Suppress warnings on non-serializable array component types in xml
b1b8350: 8275171: ProblemList compiler/codegen/aes/TestAESMain.java on linux-x64 and windows-x64 in -Xcomp mode
03c2b73: 8275128: Build hsdis using normal build system
124f823: 8268764: Use Long.hashCode() instead of int-cast where applicable
8657f77: 8271514: support JFR use of new ThreadsList::Iterator
b8bd259: 8271737: Only normalize the cached user.dir property once
... and 93 more: https://git.openjdk.java.net/jdk/compare/bb0bab57a1ff447bfb41cfe10c91838a6812b93d...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@theRealAph) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

lewurm · 2021-10-13T09:14:13Z

/integrate

openjdk · 2021-10-13T09:15:43Z

@lewurm
Your change (at version 0bf88e8) is now ready to be sponsored by a Committer.

lewurm · 2021-10-14T14:52:10Z

@theRealAph would you mind to sponsor this change?

theRealAph · 2021-10-14T16:57:27Z

/sponsor

openjdk · 2021-10-14T16:58:22Z

Going to push as commit ede3f4e.
Since your change was applied there have been 117 commits pushed to the master branch:

40d69f0: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with "RuntimeException: Unexpected log output:"
54b8870: 8275035: Clean up worker thread infrastructure
3b0b6ad: 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges
8d9004b: 8274781: Use monospace font for enclosing interface
333c469: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE
8b1b6f9: 8269559: AArch64: Implement string_compare intrinsic in SVE
d9e03e4: 8275244: Suppress warnings on non-serializable array component types in jdk.management
7dc2db4: 8274032: Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI
1e0184d: 8275234: java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in ProblemList
d15fbc2: 8275187: Suppress warnings on non-serializable array component types in java.sql.rowset
... and 107 more: https://git.openjdk.java.net/jdk/compare/bb0bab57a1ff447bfb41cfe10c91838a6812b93d...master

Your commit was automatically rebased without conflicts.

openjdk · 2021-10-14T16:58:39Z

@theRealAph @lewurm Pushed as commit ede3f4e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

lewurm · 2021-10-14T20:18:33Z

Thank you Andrew!

lewurm mentioned this pull request Oct 5, 2021

8248238: Implementation: JEP 388: Windows AArch64 Support openjdk/jdk11u-dev#301

Closed

3 tasks

openjdk bot added the rfr label Oct 5, 2021

lewurm changed the title ~~JDK-8274795: avoid spilling and restoring r18 in macro assembler~~ JDK-8274795: AArch64: avoid spilling and restoring r18 in macro assembler Oct 5, 2021

openjdk bot added the hotspot label Oct 5, 2021

fix linux/aarch64 build: s/r18/r18_tls

ba55aa0

use {push,pop}_CPU_state and fix r18 usage there as well

d7ca7b3

theRealAph reviewed Oct 13, 2021

View changes

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp Outdated Show resolved Hide resolved

theRealAph reviewed Oct 13, 2021

View changes

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp Outdated Show resolved Hide resolved

Apply suggestions from code review

0bf88e8

Co-authored-by: Andrew Haley <aph-open@littlepinkcloud.com>

theRealAph approved these changes Oct 13, 2021

View changes

openjdk bot added the ready label Oct 13, 2021

openjdk bot added the sponsor label Oct 13, 2021

openjdk bot closed this Oct 14, 2021

openjdk bot added integrated and removed ready rfr sponsor labels Oct 14, 2021

JDK-8274795: AArch64: avoid spilling and restoring r18 in macro assembler #5828

JDK-8274795: AArch64: avoid spilling and restoring r18 in macro assembler #5828

lewurm commented Oct 5, 2021 •

edited by openjdk[bot] bot

bridgekeeper bot commented Oct 5, 2021

openjdk bot commented Oct 5, 2021

mlbridge bot commented Oct 5, 2021 •

edited

VladimirKempik commented Oct 6, 2021

theRealAph commented Oct 6, 2021

VladimirKempik commented Oct 6, 2021 •

edited

theRealAph commented Oct 6, 2021

lewurm commented Oct 6, 2021

lewurm commented Oct 6, 2021

theRealAph commented Oct 6, 2021

lewurm commented Oct 6, 2021

theRealAph commented Oct 6, 2021

theRealAph commented Oct 7, 2021

lewurm commented Oct 12, 2021

theRealAph commented Oct 13, 2021

lewurm commented Oct 13, 2021

openjdk bot commented Oct 13, 2021 •

edited

lewurm commented Oct 13, 2021

openjdk bot commented Oct 13, 2021

lewurm commented Oct 14, 2021

theRealAph commented Oct 14, 2021

openjdk bot commented Oct 14, 2021

openjdk bot commented Oct 14, 2021

lewurm commented Oct 14, 2021

	__ pusha(); // XXX only save smashed registers
	__ mov(c_rarg0, rthread);
	__ mov(rscratch2, CAST_FROM_FN_PTR(address, SharedRuntime::reguard_yellow_pages));
	__ blr(rscratch2);
	__ popa(); // XXX only restore smashed registers

JDK-8274795: AArch64: avoid spilling and restoring r18 in macro assembler #5828

JDK-8274795: AArch64: avoid spilling and restoring r18 in macro assembler #5828

Conversation

lewurm commented Oct 5, 2021 • edited by openjdk[bot] bot

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Oct 5, 2021

openjdk bot commented Oct 5, 2021

mlbridge bot commented Oct 5, 2021 • edited

Webrevs

VladimirKempik commented Oct 6, 2021

theRealAph commented Oct 6, 2021

VladimirKempik commented Oct 6, 2021 • edited

theRealAph commented Oct 6, 2021

lewurm commented Oct 6, 2021

lewurm commented Oct 6, 2021

theRealAph commented Oct 6, 2021

lewurm commented Oct 6, 2021

theRealAph commented Oct 6, 2021

theRealAph commented Oct 7, 2021

lewurm commented Oct 12, 2021

theRealAph commented Oct 13, 2021

lewurm commented Oct 13, 2021

openjdk bot commented Oct 13, 2021 • edited

lewurm commented Oct 13, 2021

openjdk bot commented Oct 13, 2021

lewurm commented Oct 14, 2021

theRealAph commented Oct 14, 2021

openjdk bot commented Oct 14, 2021

openjdk bot commented Oct 14, 2021

lewurm commented Oct 14, 2021

lewurm commented Oct 5, 2021 •

edited by openjdk[bot] bot

mlbridge bot commented Oct 5, 2021 •

edited

VladimirKempik commented Oct 6, 2021 •

edited

openjdk bot commented Oct 13, 2021 •

edited