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

8256245: AArch64: Implement Base64 decoding intrinsic #3228

Closed
wants to merge 12 commits into from

Conversation

@dgbo
Copy link
Member

@dgbo dgbo commented Mar 27, 2021

In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.

Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
Tests in test/jdk/java/util/Base64/ and compiler/intrinsics/base64/TestBase64.java runned specially for the correctness of the implementation.

There can be illegal characters at the start of the input if the data is MIME encoded.
It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.

A JMH micro, Base64Decode.java, is added for performance test.
With different input length (upper-bounded by parameter maxNumBytes in the JMH micro),
we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.

The Base64Decode.java JMH micro-benchmark results:

Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units

# Kunpeng916, intrinsic
Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ±     0.609  ns/op
Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ±     1.650  ns/op
Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ±     0.931  ns/op
Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ±     1.687  ns/op
Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ±     9.217  ns/op
Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ±     1.667  ns/op
Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ±     1.751  ns/op
Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ±     1.178  ns/op
Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ±     0.584  ns/op
Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ±     1.050  ns/op
Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ±    45.172  ns/op
Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ±   192.070  ns/op
Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ±    0.336  ns/op
Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ±    0.848  ns/op
Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ±    0.608  ns/op
Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ±    6.236  ns/op
Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ±    4.670  ns/op
Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ±    4.324  ns/op
Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ±    6.393  ns/op
Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ±   0.759  ns/op
Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ±    3.422  ns/op
Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ±    9.128  ns/op
Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ± 7951.521  ns/op
Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ±  161.758  ns/op

# Kunpeng916, default
Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ±   0.571  ns/op
Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ±   0.505  ns/op
Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ±   1.452  ns/op
Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ±   1.243  ns/op
Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ±   1.188  ns/op
Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ±   0.572  ns/op
Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ±   0.177  ns/op
Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ±   0.572  ns/op
Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ±   1.559  ns/op
Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ±   0.813  ns/op
Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ±  24.669  ns/op
Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ± 523.155  ns/op
Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ±   0.238  ns/op
Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ±   0.205  ns/op
Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ±   0.610  ns/op
Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ±   4.732  ns/op
Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ±   0.177  ns/op
Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ±   4.572  ns/op
Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ±   0.301  ns/op
Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ±   0.389  ns/op
Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ±   2.519  ns/op
Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ±   9.281  ns/op
Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ± 157.920  ns/op
Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ± 216.542  ns/op

Progress

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

Issue

  • JDK-8256245: AArch64: Implement Base64 decoding intrinsic

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3228

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Mar 27, 2021

👋 Welcome back dongbo! 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 Mar 27, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Mar 27, 2021

@dgbo The following labels will be automatically applied to this pull request:

  • core-libs
  • hotspot-compiler

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

@dgbo
Copy link
Member Author

@dgbo dgbo commented Mar 27, 2021

/label add hotspot

@openjdk openjdk bot added the hotspot label Mar 27, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Mar 27, 2021

@dgbo
The hotspot label was successfully added.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Mar 27, 2021

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Mar 27, 2021

Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side.

There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.

@@ -5573,6 +5573,309 @@ class StubGenerator: public StubCodeGenerator {
return start;
}

void generate_base64_decode_nosimdround(Register src, Register dst,
Register nosimd_codec, Label &Exit)
{

This comment has been minimized.

@theRealAph

theRealAph Mar 27, 2021
Contributor

We'd want enter/leave here so profiling tools can walk the stack.

This comment has been minimized.

@nick-arm

nick-arm Mar 29, 2021
Member

That probably ought to go around the whole routine in generate_base64_decodeBlock rather than here?

address generate_base64_decodeBlock() {

static const uint8_t fromBase64ForNoSIMD[256] = {
255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u,

This comment has been minimized.

@theRealAph

theRealAph Mar 27, 2021
Contributor

There seems to be no documentation of these magic tables of constants.

This comment has been minimized.

@theRealAph

theRealAph Mar 27, 2021
Contributor

We're either going to need a proper description of the algorithm here or a permalink to one.

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Mar 27, 2021

Please consider losing the non-SIMD case. It doesn't result in any significant gain.

@@ -5573,6 +5573,309 @@ class StubGenerator: public StubCodeGenerator {
return start;
}

void generate_base64_decode_nosimdround(Register src, Register dst,
Register nosimd_codec, Label &Exit)
{

This comment has been minimized.

@nick-arm

nick-arm Mar 29, 2021
Member

That probably ought to go around the whole routine in generate_base64_decodeBlock rather than here?

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Outdated Show resolved Hide resolved
src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Outdated Show resolved Hide resolved
src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Outdated Show resolved Hide resolved
// destination. Input [64..126] is mapped to index [65, 127] in second lookup.
// The value of index 64 is set to 0, so that we know that we already get the
// decoded data with the 1st lookup.
static const uint8_t fromBase64ForSIMD[128] = {

This comment has been minimized.

@nick-arm

nick-arm Mar 29, 2021
Member

This table and the one below seem to be identical to first half of the NoSIMD tables. Can't you just use one set of 256-entry tables for both SIMD and non-SIMD algorithms?

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Outdated Show resolved Hide resolved
@nick-arm
Copy link
Member

@nick-arm nick-arm commented Mar 29, 2021

There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.

But there's only ever one of these generated at startup, right? It's not like the string intrinsics that are expanded at every call site.

@dgbo
Copy link
Member Author

@dgbo dgbo commented Mar 29, 2021

Thanks for the comments.

Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side.

As claimed in JEP 135, Base64 is frequently used to encode binary/octet sequences that are transmitted as textual data.
It is commonly used by applications using Multipurpose Internal Mail Extensions (MIME), encoding passwords for HTTP headers, message digests, etc.

There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.

There is no code unrolling in the non-SIMD case. The instructions are just loading, processing, storing data within loops.
About half of the code size is the error handling in SIMD case:
// handle illegal input
if (size == 16) {
Label ErrorInLowerHalf;
__ umov(rscratch1, in2, __ D, 0);
__ cbnz(rscratch1, ErrorInLowerHalf);

  // illegal input is in higher half, store the lower half now.
  __ st3(out0, out1, out2, __ T8B, __ post(dst, 24));

  for (int i = 8; i < 15; i++) {
    __ umov(rscratch2, in2, __ B, (u1) i);
    __ cbnz(rscratch2, Exit);
    __ umov(r10, out0, __ B, (u1) i);
    __ umov(r11, out1, __ B, (u1) i);
    __ umov(r12, out2, __ B, (u1) i);
    __ strb(r10, __ post(dst, 1));
    __ strb(r11, __ post(dst, 1));
    __ strb(r12, __ post(dst, 1));
  }
  __ b(Exit);

I think I can rewrite this part as loops.
With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?

Please consider losing the non-SIMD case. It doesn't result in any significant gain.

The non-SIMD case is useful for MIME decoding performance.
The MIME base64 encoded data is arranged in lines (line size can be set by user with maximum 76B).
Newline characters, e.g. \r\n, are illegal but can be ignored by MIME decoding.
While the SIMD case works as load data -> two vector table lookups -> combining -> error detection -> store data.
When using SIMD for MIME decoding, the 1st byte of the input are possibly a newline character.
The SIMD case will execute too much wasty code before it can detect the error and exit, with non-simd case, there are only few ldrs, orrs, strs for error detecting.

@dgbo
Copy link
Member Author

@dgbo dgbo commented Mar 29, 2021

@nick-arm Thank you for watching this.

That probably ought to go around the whole routine in generate_base64_decodeBlock rather than here?

There are two non-simd blocks in this intrinsic.
The 1st one is at the begining, mainly to roll MIME decoding to non-simd processing due to the performance issue as I claimed before.
The 2nd one is at the end to handle trailing inputs. So I guess we need generate_base64_decode_nosimdround here.

"illegal inputs". Are there existing jtreg tests that cover these cases?

Yes, they are covered by test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java.

This table and the one below seem to be identical to first half of the NoSIMD tables. Can't you just use one set of 256-entry tables for both SIMD and non-SIMD algorithms?

They are not identical, *ForSIMD[64]==0, *forNoSIMD[64]=255.
In SIMD case, *ForSIMD[64] acts as a pivot to tell us that we already get the decoded data with the 1st lookup when performing the 2nd lookup.
And input [64..126] is mapped to index [65, 127] in SIMD case, which is also different from non-SIMD case.

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Mar 29, 2021

There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.

But there's only ever one of these generated at startup, right? It's not like the string intrinsics that are expanded at every call site.

I'm talking about icache pollution. This stuff could be quite small.

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Mar 29, 2021

I think I can rewrite this part as loops.
With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?

Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.

@openjdk openjdk bot removed the rfr label Mar 30, 2021
…into one code blob, addressing other comments
@openjdk openjdk bot added the rfr label Mar 30, 2021
@dgbo dgbo force-pushed the dgbo:aarch64.base64.decode branch from f56d821 to e658ebf Mar 30, 2021
@dgbo
Copy link
Member Author

@dgbo dgbo commented Mar 30, 2021

With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?

Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.

Hi, @theRealAph @nick-arm

The code is updated. The error handling in SIMD case was rewriten as loops.

Also combined the two non-SIMD code blocks into one.
Due to we have only one non-SIMD loop now, it is moved into generate_base64_decodeBlock.
The size of the stub is 692 bytes, the non-SIMD loop takes about 92 bytes if my calculation is right.

Verified with tests test/jdk/java/util/Base64/ and compiler/intrinsics/base64/TestBase64.java.
Compared with previous implementation, the performance changes are negligible.

Other comments are addressed too. Thanks.

@dgbo
Copy link
Member Author

@dgbo dgbo commented Apr 2, 2021

PING... Any suggestions on the updated commit?

mimeEncoded.add(mimeDst);
}
}

This comment has been minimized.

@theRealAph

theRealAph Apr 2, 2021
Contributor

Are there any existing test cases for failing inputs?

@openjdk
Copy link

@openjdk openjdk bot commented Apr 6, 2021

@dgbo this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout aarch64.base64.decode
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push
@openjdk openjdk bot removed the merge-conflict label Apr 6, 2021
@dgbo
Copy link
Member Author

@dgbo dgbo commented Apr 6, 2021

Are there any existing test cases for failing inputs?

I added one, the error character is injected at the parameterized index of the encoded data.
There are no big differences for small error injected index, seems too much time is took by exception handling.
Witnessed ~x2 performance improvements for large error injected index as expected. The JMH tests:

### Kunpeng 916, intrinsic,tested with `-jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1`
Base64Decode.testBase64WithErrorInputsDecode             3           4              1  avgt   10   3696.151 ± 202.783  ns/op
Base64Decode.testBase64WithErrorInputsDecode            64           4              1  avgt   10   3899.269 ± 178.289  ns/op
Base64Decode.testBase64WithErrorInputsDecode           144           4              1  avgt   10   3902.022 ± 163.611  ns/op
Base64Decode.testBase64WithErrorInputsDecode           208           4              1  avgt   10   3982.423 ± 256.638  ns/op
Base64Decode.testBase64WithErrorInputsDecode           272           4              1  avgt   10   3984.545 ± 144.282  ns/op
Base64Decode.testBase64WithErrorInputsDecode          1000           4              1  avgt   10   4532.959 ± 310.068  ns/op
Base64Decode.testBase64WithErrorInputsDecode         20000           4              1  avgt   10  17578.148 ± 631.600  ns/op

### Kunpeng 916, default,tested with `-XX:-UseBASE64Intrinsics -jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1`
Base64Decode.testBase64WithErrorInputsDecode             3           4              1  avgt   10   3760.330 ± 261.672  ns/op
Base64Decode.testBase64WithErrorInputsDecode            64           4              1  avgt   10   3900.326 ± 121.632  ns/op
Base64Decode.testBase64WithErrorInputsDecode           144           4              1  avgt   10   4041.428 ± 174.435  ns/op
Base64Decode.testBase64WithErrorInputsDecode           208           4              1  avgt   10   4177.670 ± 214.433  ns/op
Base64Decode.testBase64WithErrorInputsDecode           272           4              1  avgt   10   4324.020 ± 106.826  ns/op
Base64Decode.testBase64WithErrorInputsDecode          1000           4              1  avgt   10   5476.469 ± 171.647  ns/op
Base64Decode.testBase64WithErrorInputsDecode         20000           4              1  avgt   10  34163.743 ± 162.263  ns/op

Your test results suggest that it isn't useful for that, surely?

The results suggest non-SIMD code provides ~11.9% improvements for MIME decoding.
Furthermore, according to local tests, we may have about ~30% performance regression for MIME decoding without non-SIMD code.

In worst case, a MIME line has only 4 base64 encoded characters and a newline string consisted of error inputs, e.g. \r\n.
When the instrinsic encounter an illegal character (\r), it has to exit.
Then the Java code will pass the next illegal source byte (\n) to the intrinsic.
With only SIMD code, it will execute too much wasty instructions before it can detect the error.
Whie with non-SIMD code, the instrinsic will execute only one non-SIMD round for this error input.

For loads and four post increments rather than one load and a few BFMs? Why?

Nice suggestion. Done, thanks.

@theRealAph
Copy link
Contributor

@theRealAph theRealAph commented Apr 6, 2021

There can be illegal characters at the start of the input if the data is MIME encoded.
It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.

What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters.

@dgbo
Copy link
Member Author

@dgbo dgbo commented Apr 6, 2021

It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.

What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters.

The code here is supposed to guarantee we won’t have performance regression for any input, even if the input contains too much illegal characters, like MIME encoded data with 4 characters and a newline string as mentioned before.

If there are no illegal characters, this code block will process only 80B of the inputs, including MIME encoded data.
After that, the stub will use the SIMD instructions to process the rest of the inputs if the data length is large enough, i.e. >= 64B, to form up at least one SIMD round.

__ cmp(length, (u1)144); // 144 = 80 + 64
__ br(Assembler::LT, Process4B);

// The 1st character of the input can be illegal if the data is MIME encoded.

This comment has been minimized.

@theRealAph

theRealAph Apr 6, 2021
Contributor

Why is this sentence here? It is very misleading.

This comment has been minimized.

@dgbo

dgbo Apr 7, 2021
Author Member

This sentence was used to describe the worst case observed frequently so that readers can understand more easily why the pre-processing non-SIMD code is necessary.
I apologize for being unclear and misleading. The annotations have been modified as suggested.

__ orrw(r13, r13, r12, Assembler::LSL, 6);
__ strb(r14, __ post(dst, 1));
__ strb(r15, __ post(dst, 1));
__ strb(r13, __ post(dst, 1));

This comment has been minimized.

@theRealAph

theRealAph Apr 7, 2021
Contributor

I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think.

This comment has been minimized.

@theRealAph

theRealAph Apr 7, 2021
Contributor

Sorry, that's not quite right, but you get the idea: let's not generate unnecessary memory traffic.

This comment has been minimized.

@dgbo

dgbo Apr 8, 2021
Author Member

Okay, implemented as:

__ lslw(r14, r10, 10);
__ bfiw(r14, r11, 4, 6);
__ bfmw(r14, r12, 2, 5);
__ rev16w(r14, r14);
__ bfiw(r13, r12, 6, 2);
__ strh(r14, __ post(dst, 2));
__ strb(r13, __ post(dst, 1));
@openjdk
Copy link

@openjdk openjdk bot commented Apr 8, 2021

@dgbo 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:

8256245: AArch64: Implement Base64 decoding intrinsic

Reviewed-by: aph, ngasson

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 28 new commits pushed to the master branch:

  • ec599da: 8264633: Add missing logging to PlatformRecording#stop
  • e89542f: 8264352: AArch64: Optimize vector "not/andNot" for NEON and SVE
  • 016db40: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to
  • 78d1164: 8214455: Relocate CDS archived regions to the top of the G1 heap
  • 88eb291: 8264809: test-lib fails to build due to some warnings in ASN1Formatter and jfr
  • a863ab6: 8264551: Unexpected warning when jpackage creates an exe
  • 6e2b82a: 8264731: Introduce InstanceKlass::method_at_itable_or_null()
  • 22b20f8: 8264424: Support OopStorage bulk allocation
  • ab3be72: 8264863: Update JCov version to support JDK 17
  • 774e5ae: 8264742: member variable _monitor of MonitorLocker is redundant
  • ... and 18 more: https://git.openjdk.java.net/jdk/compare/81325483d8ef95a597349e18dc8413eeb8a45008...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, @nick-arm) 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 Apr 8, 2021
@dgbo
Copy link
Member Author

@dgbo dgbo commented Apr 8, 2021

@theRealAph Thanks for the review.

Hi @nick-arm, are you also ok with the newest commit?

@nick-arm
Copy link
Member

@nick-arm nick-arm commented Apr 8, 2021

Hi @nick-arm, are you also ok with the newest commit?

It looks ok to me but I'm not a Reviewer.

@dgbo
Copy link
Member Author

@dgbo dgbo commented Apr 8, 2021

/integrate

@openjdk openjdk bot added the sponsor label Apr 8, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 8, 2021

@dgbo
Your change (at version ab0e405) is now ready to be sponsored by a Committer.

@RealFYang
Copy link
Member

@RealFYang RealFYang commented Apr 9, 2021

/sponsor

@openjdk openjdk bot closed this Apr 9, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 9, 2021

@RealFYang @dgbo Since your change was applied there have been 40 commits pushed to the master branch:

  • 57f1e7d: 8264696: Multi-catch clause causes compiler exception because it uses the package-private supertype
  • 3d2b4cc: 8264864: Multiple byte tag not supported by ASN.1 encoding
  • ccefa5e: 8261625: Add Elements.isAutomaticModule(ModuleElement)
  • 8a23580: 8264428: Cleanup usages of StringBuffer in java.desktop
  • 308f679: 8264454: Jaxp unit test from open jdk needs to be improved
  • 5bd6c74: 8236127: Use value of --icon CLI option to set icon for exe installers
  • 81d35e4: 8264063: Outer Safepoint poll load should not reference the head of inner strip mined loop.
  • 04fa1ed: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch
  • 214d6e2: 8263506: Make sun.net.httpserver.UnmodifiableHeaders unmodifiable
  • af13c64: 8264711: More runtime TRAPS cleanups
  • ... and 30 more: https://git.openjdk.java.net/jdk/compare/81325483d8ef95a597349e18dc8413eeb8a45008...master

Your commit was automatically rebased without conflicts.

Pushed as commit 77b1673.

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

@dgbo dgbo deleted the dgbo:aarch64.base64.decode branch Apr 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants