Re: RFR: 8267630: Start of release updates for JDK 18 [v4]
> 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/5aafa154...f926c1bc - Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/fc4d8725..f926c1bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4175=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4175=02-03 Stats: 2678 lines in 127 files changed: 1537 ins; 898 del; 243 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175
RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. Benchmark Name | Base Score | Optimized Score | Gain -- | -- | -- | -- testBase64Decode size 1 | 15.36 | 15.32 | 1.00 testBase64Decode size 3 | 17.00 | 16.72 | 1.02 testBase64Decode size 7 | 20.60 | 18.82 | 1.09 testBase64Decode size 32 | 34.21 | 26.77 | 1.28 testBase64Decode size 64 | 54.43 | 38.35 | 1.42 testBase64Decode size 80 | 66.40 | 48.34 | 1.37 testBase64Decode size 96 | 73.16 | 52.90 | 1.38 testBase64Decode size 112 | 84.93 | 51.82 | 1.64 testBase64Decode size 512 | 288.81 | 32.04 | 9.01 testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 testBase64Decode size 2 | 9530.28 | 483.37 | 19.72 testBase64Decode size 5 | 24552.24 | 1735.07 | 14.15 testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 testBase64MIMEDecode size 2 | 70484.09 | 64940.77 | 1.09 testBase64MIMEDecode size 5 | 191732.34 | 158158.95 | 1.21 testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 testBase64WithErrorInputsDecode size 2 | 1398.44 | 1138.17 | 1.23 testBase64WithErrorInputsDecode size 5 | 1409.41 | 1114.16 | 1.26 - Commit messages: - Merge remote-tracking branch 'origin/base64_length_restrict' into base64_decode - Condition decode intrinsic within generator instead of outside to allow non-AVX acceleration - Adding MIME to signature. - Adding MIME to signature. - Adding MIME to signature. - Initialize vector before loop - Initialize vector before loop - Wrong register lengths. - Wrong register lengths. - writing in wrong order - ... and 418 more: https://git.openjdk.java.net/jdk/compare/48dc72b7...e527557a Changes: https://git.openjdk.java.net/jdk/pull/4368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4368=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268276 Stats: 743 lines in 10 files changed: 736 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368
Re: RFR: 8268227: java/foreign/TestUpcall.java still times out
On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore wrote: > Turns out that adding more timeout is a lost cause here. The root cause of > the slowdown when running the test in debug build is: > > https://bugs.openjdk.java.net/browse/JDK-8266074 > > Which has also caused related test issues: > > https://bugs.openjdk.java.net/browse/JDK-8268095 > > So, the fix (at least temporarily) is to run method handle-heavy tests with > the -XX:-VerifyDependency options. > > On my machine, execution time of these tests on debug goes from 10 minutes > down to less than 1. > > Since `-XX:-VerifyDependencies` cannot be specified on non-debug build, the > `-XX:+IgnoreUnrecognizedVMOptions` is also passed (thanks Vlad for the tip!). Thumbs up! -XX:-VerifyDependencies is useful for getting around the non-release bits slowness added by the new CHA based stuff added by: JDK-8266074 Vtable-based CHA implementation - Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4355
Integrated: 8266846: Add java.time.InstantSource
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource This pull request has now been integrated. Changeset: 6c838c56 Author:Stephen Colebourne Committer: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/6c838c568c2c99145fd0ae8059de2b2865b65863 Stats: 623 lines in 6 files changed: 536 ins; 64 del; 23 mod 8266846: Add java.time.InstantSource Reviewed-by: rriggs, naoto, darcy - PR: https://git.openjdk.java.net/jdk/pull/4016
Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v13]
On Fri, 4 Jun 2021 20:20:26 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for >> switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common >> superinterface for expressions and patterns, `CaseLabelTree`, which >> expressions and patterns implement, and a list of case labels is returned >> from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` >> that represents it (`DefaultCaseLabelTree`). It is used also to represent >> the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be >> disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary >> (boxed-primitive, String, enum) switches. This is a bit tricky for boxed >> primitives, as there is no value that is not part of the input domain so >> that could be used to represent `case null`. Requires a bit shuffling with >> values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It >> produces code that delegates to a new bootstrap method, that will classify >> the input value to the switch and return the case number, to which the >> switch then jumps. To support guards, the switches (and the bootstrap >> method) are restartable. The bootstrap method as such is written very simply >> so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String >> s`/`case null: case String s:`/`case String s: case null:`, handling of >> these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with two additional > commits since the last revision: > > - Applying review feedback. > - Tweaking javadoc. Dynamic constants are needed when de-structuring classes that are not record at top-level, to make the type that will carry the bindings, from invokedynamic to where they are accessed, opaque. So dynamic constants are not needed yet ! - PR: https://git.openjdk.java.net/jdk/pull/3863
Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12]
On Fri, 4 Jun 2021 20:17:43 GMT, Jan Lahoda wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixing typo. > > Thanks a lot for all the feedback. I've tried to do the requested changes in > the recent commits. @lahodaj I also noticed that https://bugs.openjdk.java.net/browse/JDK-8213076 as well as https://openjdk.java.net/jeps/406 state > The implementation will likely make use of dynamic constants (JEP 309). and wondering if this should be changed on > The implementation will likely make use of invokedynamic. or maybe even removed? - PR: https://git.openjdk.java.net/jdk/pull/3863
