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

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

Closed
wants to merge 5 commits into from

Conversation

lewurm
Copy link
Member

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

__ 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

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
Copy link

@bridgekeeper bridgekeeper bot commented Oct 5, 2021

👋 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 openjdk bot added the rfr label Oct 5, 2021
@lewurm 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
Copy link

@openjdk openjdk bot commented Oct 5, 2021

@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.

@openjdk openjdk bot added the hotspot label Oct 5, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Oct 5, 2021

Webrevs

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Oct 6, 2021

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

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Oct 6, 2021

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

@VladimirKempik
Copy link

@VladimirKempik VladimirKempik commented Oct 6, 2021

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
Copy link
Contributor

@theRealAph theRealAph commented Oct 6, 2021

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
Copy link
Member Author

@lewurm lewurm commented Oct 6, 2021

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:

__ 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
Copy link
Member Author

@lewurm lewurm commented Oct 6, 2021

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
Copy link
Contributor

@theRealAph theRealAph commented Oct 6, 2021

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
Copy link
Member Author

@lewurm lewurm commented Oct 6, 2021

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
Copy link
Contributor

@theRealAph theRealAph commented Oct 6, 2021

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
Copy link
Contributor

@theRealAph theRealAph commented Oct 7, 2021

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
Copy link
Member Author

@lewurm lewurm commented Oct 12, 2021

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
Copy link
Contributor

@theRealAph theRealAph commented Oct 13, 2021

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.

Co-authored-by: Andrew Haley <aph-open@littlepinkcloud.com>
@lewurm
Copy link
Member Author

@lewurm lewurm commented Oct 13, 2021

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
Copy link

@openjdk openjdk bot commented Oct 13, 2021

@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).

@openjdk openjdk bot added the ready label Oct 13, 2021
@lewurm
Copy link
Member Author

@lewurm lewurm commented Oct 13, 2021

/integrate

@openjdk openjdk bot added the sponsor label Oct 13, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Oct 13, 2021

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

@lewurm
Copy link
Member Author

@lewurm lewurm commented Oct 14, 2021

@theRealAph would you mind to sponsor this change?

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Oct 14, 2021

/sponsor

@openjdk
Copy link

@openjdk openjdk bot commented Oct 14, 2021

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 openjdk bot closed this Oct 14, 2021
@openjdk openjdk bot added integrated and removed ready rfr sponsor labels Oct 14, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Oct 14, 2021

@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
Copy link
Member Author

@lewurm lewurm commented Oct 14, 2021

Thank you Andrew!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot integrated
3 participants