Re: RFR: 8315999: Improve Date toString performance [v13]
> improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString 温绍锦 has updated the pull request incrementally with one additional commit since the last revision: simplify LocalDate::getChars - Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/d3ad4906..b7a3528c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=11-12 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658
Re: RFR: 8315999: Improve Date toString performance [v13]
On Tue, 12 Sep 2023 22:53:34 GMT, Claes Redestad wrote: >> The reason for not using off++ is that it can be executed out of order, >> which may result in better performance. > > I don't think that would outweigh the extra branch and the increased code > size. I'd opt for simplicity. I've simplified LocalDate::getChars based on your suggestion - PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1324587746
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It > would improve readability to see the native characters instead of escape > sequences (especially for the L10n process). The majority of files changed > are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties > files (both in src and test) to UTF-8 native characters. Additionally, the > build logic is adjusted to read the .properties files in UTF-8 while > generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote > intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding > UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need > to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 > unless manually changed). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Replace InputStreamReader with BufferedReader - Changes: - all: https://git.openjdk.org/jdk/pull/15694/files - new: https://git.openjdk.org/jdk/pull/15694/files/0f3698a5..ceb48bbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00-01 Stats: 18 lines in 2 files changed: 6 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694 PR: https://git.openjdk.org/jdk/pull/15694
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. >> It would improve readability to see the native characters instead of escape >> sequences (especially for the L10n process). The majority of files changed >> are localized resource files. >> >> This change converts the Unicode escape sequences in the JDK .properties >> files (both in src and test) to UTF-8 native characters. Additionally, the >> build logic is adjusted to read the .properties files in UTF-8 while >> generating the ListResourceBundle files. >> >> The only escape sequence not converted was `\u0020` as this is used to >> denote intentional trailing white space. (E.g. `key=This is the >> value:\u0020`) >> >> The conversion was done using native2ascii with options `-reverse -encoding >> UTF-8`. >> >> If this PR is integrated, the IDE default encoding for .properties files >> need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as >> ISO-8859-1 unless manually changed). > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > Replace InputStreamReader with BufferedReader Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion. - Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15694#pullrequestreview-1625154951
RFR: 4964430: Missing IllegalStateException exception requirement for javax.crypto.Cipher.doFinal
Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap` - Commit messages: - Updated IllegalStateException requirement in update, doFinal, wrap, and unwrap Changes: https://git.openjdk.org/jdk/pull/15727/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15727&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4964430 Stats: 27 lines in 1 file changed: 12 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15727/head:pull/15727 PR: https://git.openjdk.org/jdk/pull/15727
Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]
On Wed, 13 Sep 2023 18:12:15 GMT, Naoto Sato wrote: > Looks good to me, although I did not look at each l10n file, but sampled > some. Thanks for tackling this conversion. Thanks for the review; (In addition to testing), I ran a script to verify only white space escape sequences exist in JDK .properties files. (Excluding escape sequences in test files that should remain as is for the purpose of the test) - PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-1718139807
Re: RFR: 8315999: Improve Date toString performance [v13]
On Wed, 13 Sep 2023 14:22:35 GMT, 温绍锦 wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > 温绍锦 has updated the pull request incrementally with one additional commit > since the last revision: > > simplify LocalDate::getChars Based on the use cases cited, if your library needs specific performance improvements for specific formats, they should be done in that library. - PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718186604
Re: RFR: 8315999: Improve Date toString performance [v13]
On Wed, 13 Sep 2023 14:22:35 GMT, 温绍锦 wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > 温绍锦 has updated the pull request incrementally with one additional commit > since the last revision: > > simplify LocalDate::getChars As a consideration to core-libs-dev readers, push commits when you are convinced are ready for review and you don't intend to make more changes. It will improve the signal to noise ratio. Thanks - PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718192179
Re: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2]
> Hi All, > I would like to submit AES-GCM optimization for x86_64 architectures using > AVX2 instructions. This optimization interleaves AES and GHASH operations. > > Below are the performance numbers on my desktop system with -XX:UseAVX=2 > option: > > |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | > Speedup > |-||---|--|---| > |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 > full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 > small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 > small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 > full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 > full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 > small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 > small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 > | | | | > full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 > full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 > small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 > small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 > full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 > full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 > small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 > small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 > | | | | > full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 > full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 > small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 > small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 > full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 > full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 > small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 > small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 > | | | | > full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 > full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 > small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 > small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 > full.AESGCMBench.decryptMultiPart | 65536 | 42649.816 | 47591.587 |1.11 > full.AESGCMBe... Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Removed isEncrypt boolean variable - Changes: - all: https://git.openjdk.org/jdk/pull/15410/files - new: https://git.openjdk.org/jdk/pull/15410/files/33b1d980..2727c199 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=00-01 Stats: 43 lines in 8 files changed: 0 ins; 10 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/15410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15410/head:pull/15410 PR: https://git.openjdk.org/jdk/pull/15410
RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java
sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. - Commit messages: - Updated Copyright and remove excess new line - Parallelize sun/security/util/math/TestIntegerModuloP.java Changes: https://git.openjdk.org/jdk/pull/15618/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15618&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315684 Stats: 62 lines in 1 file changed: 60 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15618/head:pull/15618 PR: https://git.openjdk.org/jdk/pull/15618
Re: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java
On Thu, 7 Sep 2023 13:28:15 GMT, Aleksey Shipilev wrote: >> sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about >> 600 seconds to run. Thus, it drags the execution time of tier2 on large >> machines. We can split the run configurations a bit so that test is more >> parallel. >> >> TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% >> cpu 3:22.69 total** >> TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system >> 755% cpu 45.467 total** >> >> This change splits TestIntegerModuloP.java's previously serialized test into >> 11 separate tests that run in parallel. > > test/jdk/sun/security/util/math/TestIntegerModuloP.java line 103: > >> 101: */ >> 102: >> 103: > > Excess new line. Updated with Copyright and removed the excess line. Please see latest commit. - PR Review Comment: https://git.openjdk.org/jdk/pull/15618#discussion_r1318622985
Re: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java
On Thu, 7 Sep 2023 13:23:01 GMT, Ian Myers wrote: > sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about > 600 seconds to run. Thus, it drags the execution time of tier2 on large > machines. We can split the run configurations a bit so that test is more > parallel. > > TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% > cpu 3:22.69 total** > TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system > 755% cpu 45.467 total** > > This change splits TestIntegerModuloP.java's previously serialized test into > 11 separate tests that run in parallel. Please go https://github.com/ianrichr/jdk/actions and enable testing for your personal fork. Then please update copyright in the file to: * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved. ...and push another commit here. This will trigger testing too. This looks fine. I suggested @ianrichr what to do for this RFE, so I would like someone else to take a look too. Hi @robilad, could you help us with OCA verification here a bit? Thanks! test/jdk/sun/security/util/math/TestIntegerModuloP.java line 103: > 101: */ > 102: > 103: Excess new line. - PR Review: https://git.openjdk.org/jdk/pull/15618#pullrequestreview-1615439495 Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15618#pullrequestreview-1615484644 PR Comment: https://git.openjdk.org/jdk/pull/15618#issuecomment-1715606358 PR Review Comment: https://git.openjdk.org/jdk/pull/15618#discussion_r1318610805
Re: RFR: 8315999: Improve Date toString performance [v13]
On Wed, 13 Sep 2023 19:21:34 GMT, Roger Riggs wrote: > Based on the use cases cited, if your library needs specific performance > improvements for specific formats, they should be done in that library. I already do this in [fastjson2](https://github.com/alibaba/fastjson2) for now, but more libraries would benefit if improved in jdk. - PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718334638
Re: RFR: 8315999: Improve Date toString performance [v13]
On Wed, 13 Sep 2023 14:22:35 GMT, 温绍锦 wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > 温绍锦 has updated the pull request incrementally with one additional commit > since the last revision: > > simplify LocalDate::getChars > As a consideration to core-libs-dev readers, push commits when you are > convinced are ready for review and you don't intend to make more changes. It > will improve the signal to noise ratio. Thanks > As a consideration to core-libs-dev readers, push commits when you are > convinced are ready for review and you don't intend to make more changes. It > will improve the signal to noise ratio. Thanks Sorry, I will make sure to do more preparation before submitting any PRs in the future. - PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718372907
Re: RFR: 8315999: Improve Date toString performance [v13]
On Wed, 13 Sep 2023 21:22:43 GMT, 温绍锦 wrote:
> Based on the use cases cited, if your library needs specific performance
> improvements for specific formats, they should be done in that library.
Not only JSON libraries, toString optimization of Date/Instant/LocalDateTime
and other classes will benefit in many places, such as logging in business
systems, etc.
Instant bizTime = ...;
LOG.log(Level.INFO, "bizDate {0}", bizTime);
-
PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718401009
Re: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2]
On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote:
>> Hi All,
>> I would like to submit AES-GCM optimization for x86_64 architectures using
>> AVX2 instructions. This optimization interleaves AES and GHASH operations.
>>
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2
>> option:
>>
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) |
>> Speedup
>> |-||---|--|---|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> | | | |
>> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> | | | |
>> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30
>> | | | |
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removed isEncrypt boolean variable
src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 362:
> 360: // AVX2 AES-GCM related functions
> 361: void initial_blocks(XMMRegister ctr, Register rounds, Register key,
> Register len,
> 362: Register in, Register out, Register ct, Register
> subkeyHtbl, Register pos);
You could rename it to gcm_intial_blocks_avx2().
src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 365:
> 363: void gfmul_avx2(XMMRegister GH, XMMRegister HK);
> 364: void generateHtbl_8_block_avx2(Register htbl, Register rscratch);
> 365: void ghash8_encrypt8_parallel(Register key, Register subkeyHtbl,
> XMMRegister ctr_blockx, XMMRegister aad_hashx,
Rename to ghash8_encrypt8_parallel_avx2().
src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 367:
> 365: void ghash8_encrypt8_parallel(Register key, Register subkeyHtbl,
> XMMRegister ctr_blockx, XMMRegister aad_hashx,
> 366: Register in, Register out, Register ct,
> Register pos, bool out_order, Register rounds);
> 367: void ghash_last_8(Register subkeyHtbl);
Rename to ghash_last_8_avx2.
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 185:
> 183: if (VM_Version::supports_avx2()) {
> 184: StubRoutines::_galoisCounterMode_AESCrypt =
> generate_avx2_galoisCounterMode_AESCrypt();
> 185: }
This could be moved to line 192.
src/hotspot/cpu/x86/stubRoutines_x86.hpp line 40:
> 38: // AVX512 intrinsics add more code in 64-bit VM,
> 39: // Windows have more code to save/restore registers
> 40: _compiler_stubs_code_size = 3 LP64_ONLY(+3)
> WINDOWS_ONLY(+2000),
Since the stub is for 64 bit, the LP64_ONLY part needs to increase and not the
base.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325143256
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325143499
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325143801
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325145931
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325144430
Re: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2]
On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote:
>> Hi All,
>> I would like to submit AES-GCM optimization for x86_64 architectures using
>> AVX2 instructions. This optimization interleaves AES and GHASH operations.
>>
>> Below are the performance numbers on my desktop system with -XX:UseAVX=2
>> option:
>>
>> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) |
>> Speedup
>> |-||---|--|---|
>> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27
>> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26
>> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25
>> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24
>> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99
>> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00
>> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99
>> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99
>> | | | |
>> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27
>> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27
>> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27
>> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27
>> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13
>> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24
>> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12
>> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26
>> | | | |
>> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31
>> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30
>> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29
>> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28
>> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12
>> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27
>> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12
>> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30
>> | | | |
>> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30
>> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31
>> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32
>> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32
>> full.AES...
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removed isEncrypt boolean variable
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3399:
> 3397: __ vpshufb(xmm6, xmm6, t5, Assembler::AVX_128bit); //perform a
> 16Byte swap
> 3398: __ vpshufb(xmm7, xmm7, t5, Assembler::AVX_128bit); //perform a
> 16Byte swap
> 3399: __ vpshufb(xmm8, xmm8, t5, Assembler::AVX_128bit); //perform a
> 16Byte swap
This could be written in a loop:
for (int rnum = 1; rnum <= 8; rnum++) {
__ vpshufb(as_XMMRegister(rnum), as_XMMRegister(rnum), t5,
Assembler::AVX_128bit);
}
Similar technique can be used in some places below.
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4040:
> 4038: __ aesenc(xmm6, t_key);
> 4039: __ aesenc(xmm7, t_key);
> 4040: __ aesenc(xmm8, t_key);
This code is repeated multiple times so can be generated through a method like
aesenc_step_avx2(t_key);
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325200254
PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325180777
RFR: 8316235: Optimization for DateTimeFormatter::format
In many scenarios, DateTimeFormatter::format is a slower operation. For example, the following business scenarios 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings. 2. In data integration scenarios, for projects like [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required. This PR provides format performance optimization for commonly used date patterns. ISO_INSTANT ISO_LOCAL_TIME ISO_LOCAL_DATE ISO_LOCAL_DATETIME HH:mm:ss HH:mm:ss.SSS -MM-dd -MM-dd HH:mm:ss -MM-dd'T'HH:mm:ss -MM-dd HH:mm:ss.SSS -MM-dd'T'HH:mm:ss.SSS - Commit messages: - fix format LocalTime/LocalDateTime use utc - fix format ZonedDateTime & OffsetDateTime & OffsetTime use utc - sealed class CompositePrinterParser - use Pattern Matching switch - remove LocalTimePrinterParser::format support Instant - optimization support pattern '-MM-dd HH:mm:ss.SSS' - remove digit_k - optimize DateTimeFormatter::format - fix InstantPrinterParser miss nanos - remove TimeCompositePrinterParser, fix build error - ... and 1 more: https://git.openjdk.org/jdk/compare/e0845163...564ae18b Changes: https://git.openjdk.org/jdk/pull/15722/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15722&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316235 Stats: 418 lines in 6 files changed: 341 ins; 51 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/15722.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15722/head:pull/15722 PR: https://git.openjdk.org/jdk/pull/15722
Re: RFR: 8316235: Optimization for DateTimeFormatter::format
On Wed, 13 Sep 2023 14:56:15 GMT, 温绍锦 wrote: > In many scenarios, DateTimeFormatter::format is a slower operation. > > For example, the following business scenarios > 1. The json library > gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats > Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings. > 2. In data integration scenarios, for projects like > [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), > if the input type is Date/Instant and the output type is String, formatting > is required. > > This PR provides format performance optimization for commonly used date > patterns. > > ISO_INSTANT > ISO_LOCAL_TIME > ISO_LOCAL_DATE > ISO_LOCAL_DATETIME > HH:mm:ss > HH:mm:ss.SSS > -MM-dd > -MM-dd HH:mm:ss > -MM-dd'T'HH:mm:ss > -MM-dd HH:mm:ss.SSS > -MM-dd'T'HH:mm:ss.SSS Performance comparison data is as follows: ## 1. Script bash configure make images sh make/devkit/createJMHBundle.sh bash configure --with-jmh=build/jmh/jars make test TEST="micro:java.time.format.DateTimeFormatterBench.*" ## 2. MacBookPro benchmark -Benchmark (pattern) Mode Cnt Score Error Units (baseline) -DateTimeFormatterBench.formatInstantsHH:mm:ss thrpt 15 14.888 ? 0.109 ops/ms -DateTimeFormatterBench.formatInstantsHH:mm:ss.SSS thrpt 15 10.132 ? 0.046 ops/ms -DateTimeFormatterBench.formatInstants -MM-dd'T'HH:mm:ss thrpt 15 8.993 ? 0.039 ops/ms -DateTimeFormatterBench.formatInstants -MM-dd'T'HH:mm:ss.SSS thrpt 15 7.400 ? 0.035 ops/ms -DateTimeFormatterBench.formatZonedDateTime HH:mm:ss thrpt 15 21.460 ? 0.056 ops/ms -DateTimeFormatterBench.formatZonedDateTime HH:mm:ss.SSS thrpt 15 14.439 ? 0.264 ops/ms -DateTimeFormatterBench.formatZonedDateTime -MM-dd'T'HH:mm:ss thrpt 15 12.742 ? 0.055 ops/ms -DateTimeFormatterBench.formatZonedDateTime -MM-dd'T'HH:mm:ss.SSS thrpt 15 9.059 ? 0.124 ops/ms +Benchmark (pattern) Mode Cnt Score Error Units (optimized) +DateTimeFormatterBench.formatInstantsHH:mm:ss thrpt 15 28.082 ? 0.284 ops/ms (+88.62%) +DateTimeFormatterBench.formatInstantsHH:mm:ss.SSS thrpt 15 25.483 ? 0.109 ops/ms (+151.51%) +DateTimeFormatterBench.formatInstants -MM-dd'T'HH:mm:ss thrpt 15 19.950 ? 0.444 ops/ms (+121.83%) +DateTimeFormatterBench.formatInstants -MM-dd'T'HH:mm:ss.SSS thrpt 15 18.391 ? 0.327 ops/ms (+148.52%) +DateTimeFormatterBench.formatZonedDateTime HH:mm:ss thrpt 15 57.870 ? 0.641 ops/ms (+169.66%) +DateTimeFormatterBench.formatZonedDateTime HH:mm:ss.SSS thrpt 15 43.783 ? 0.300 ops/ms (+203.22%) +DateTimeFormatterBench.formatZonedDateTime -MM-dd'T'HH:mm:ss thrpt 15 36.220 ? 0.194 ops/ms (+184.25%) +DateTimeFormatterBench.formatZonedDateTime -MM-dd'T'HH:mm:ss.SSS thrpt 15 32.512 ? 0.583 ops/ms (+258.89%) - PR Comment: https://git.openjdk.org/jdk/pull/15722#issuecomment-1717870613
Re: RFR: 8316235: Optimization for DateTimeFormatter::format
On Wed, 13 Sep 2023 18:52:21 GMT, ExE Boss wrote:
>> In many scenarios, DateTimeFormatter::format is a slower operation.
>>
>> For example, the following business scenarios
>> 1. The json library
>> gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats
>> Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings.
>> 2. In data integration scenarios, for projects like
>> [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal),
>> if the input type is Date/Instant and the output type is String, formatting
>> is required.
>>
>> This PR provides format performance optimization for commonly used date
>> patterns.
>>
>> ISO_INSTANT
>> ISO_LOCAL_TIME
>> ISO_LOCAL_DATE
>> ISO_LOCAL_DATETIME
>> HH:mm:ss
>> HH:mm:ss.SSS
>> -MM-dd
>> -MM-dd HH:mm:ss
>> -MM-dd'T'HH:mm:ss
>> -MM-dd HH:mm:ss.SSS
>> -MM-dd'T'HH:mm:ss.SSS
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
> line 2661:
>
>> 2659: } else {
>> 2660: return super.format(context, buf);
>> 2661: }
>
> This can use `instanceof `:
> Suggestion:
>
> if (temporal instanceof LocalTime lt) {
> time = lt;
> } else if (temporal instanceof LocalDateTime ldt) {
> time = ldt.toLocalTime();
> } else if (temporal instanceof ZonedDateTime zdt) {
> time = zdt.toLocalTime();
> } else if (temporal instanceof OffsetDateTime odt) {
> time = odt.toLocalTime();
> } else if (temporal instanceof OffsetTime ot) {
> time = ot.toLocalTime();
> } else {
> return super.format(context, buf);
> }
>
>
> Or even a pattern switch:
> Suggestion:
>
> switch (temporal) {
> case LocalTime lt -> time = lt;
> case LocalDateTime ldt -> time = ldt.toLocalTime();
> case ZonedDateTime zdt -> time = zdt.toLocalTime();
> case OffsetDateTime odt -> time = odt.toLocalTime();
> case OffsetTime ot -> time = ot.toLocalTime();
> default -> {
> return super.format(context, buf);
> }
> }
It's a good idea to use the new switch syntax
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
> line 2683:
>
>> 2681: * Composite printer and parser.
>> 2682: */
>> 2683: static class CompositePrinterParser implements
>> DateTimePrinterParser {
>
> This class can be `sealed`:
> Suggestion:
>
> static sealed class CompositePrinterParser implements
> DateTimePrinterParser {
Changes have been made based on your suggestions
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1325113374
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1325112780
Re: RFR: 8316235: Optimization for DateTimeFormatter::format
On Wed, 13 Sep 2023 14:56:15 GMT, 温绍锦 wrote:
> In many scenarios, DateTimeFormatter::format is a slower operation.
>
> For example, the following business scenarios
> 1. The json library
> gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats
> Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings.
> 2. In data integration scenarios, for projects like
> [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal),
> if the input type is Date/Instant and the output type is String, formatting
> is required.
>
> This PR provides format performance optimization for commonly used date
> patterns.
>
> ISO_INSTANT
> ISO_LOCAL_TIME
> ISO_LOCAL_DATE
> ISO_LOCAL_DATETIME
> HH:mm:ss
> HH:mm:ss.SSS
> -MM-dd
> -MM-dd HH:mm:ss
> -MM-dd'T'HH:mm:ss
> -MM-dd HH:mm:ss.SSS
> -MM-dd'T'HH:mm:ss.SSS
src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line
2594:
> 2592: } else {
> 2593: return super.format(context, buf);
> 2594: }
This can use `instanceof `:
Suggestion:
if (temporal instanceof LocalDateTime ldt) {
date = ldt.toLocalDate();
} else if (temporal instanceof LocalDate ld) {
date = ld;
} else if (temporal instanceof ZonedDateTime zdt) {
date = zdt.toLocalDate();
} else if (temporal instanceof OffsetDateTime odt) {
date = odt.toLocalDate();
} else {
return super.format(context, buf);
}
Or even a pattern switch:
Suggestion:
switch (temporal) {
case LocalDateTime ldt -> date = ldt.toLocalDate();
case LocalDate ld -> date = ld;
case ZonedDateTime zdt -> date = zdt.toLocalDate();
case OffsetDateTime odt -> date = odt.toLocalDate();
default -> {
return super.format(context, buf);
}
}
src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line
2661:
> 2659: } else {
> 2660: return super.format(context, buf);
> 2661: }
This can use `instanceof `:
Suggestion:
if (temporal instanceof LocalTime lt) {
time = lt;
} else if (temporal instanceof LocalDateTime ldt) {
time = ldt.toLocalTime();
} else if (temporal instanceof ZonedDateTime zdt) {
time = zdt.toLocalTime();
} else if (temporal instanceof OffsetDateTime odt) {
time = odt.toLocalTime();
} else if (temporal instanceof OffsetTime ot) {
time = ot.toLocalTime();
} else {
return super.format(context, buf);
}
Or even a pattern switch:
Suggestion:
switch (temporal) {
case LocalTime lt -> time = lt;
case LocalDateTime ldt -> time = ldt.toLocalTime();
case ZonedDateTime zdt -> time = zdt.toLocalTime();
case OffsetDateTime odt -> time = odt.toLocalTime();
case OffsetTime ot -> time = ot.toLocalTime();
default -> {
return super.format(context, buf);
}
}
src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line
2683:
> 2681: * Composite printer and parser.
> 2682: */
> 2683: static class CompositePrinterParser implements
> DateTimePrinterParser {
This class can be `sealed`:
Suggestion:
static sealed class CompositePrinterParser implements DateTimePrinterParser
{
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324933754
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324937172
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324941838
Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v5]
> We should set the -permissive- flag for the Microsoft Visual C compiler, as > was requested by the now backed out > [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes > the Visual C compiler much less accepting of ill formed code, which will > improve code quality on Windows in the future. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into patch-10 - Document changes in awt_DnDDS.cpp - Remove negation in os_windows.cpp - Mismatched declaration in D3DGlyphCache.cpp - Fields in awt_TextComponent.cpp - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp - Qualifiers in awt_PrintDialog.h should be removed - Likewise for awt_DnDDT.cpp - awt_ole.h include order issue in awt_DnDDS.cpp - Revert awt_ole.h - ... and 15 more: https://git.openjdk.org/jdk/compare/11d431b2...1d3d6b5e - Changes: https://git.openjdk.org/jdk/pull/15096/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=04 Stats: 802 lines in 17 files changed: 171 ins; 127 del; 504 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096
Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4]
On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes >> the Visual C compiler much less accepting of ill formed code, which will >> improve code quality on Windows in the future. > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Document changes in awt_DnDDS.cpp Pinging - PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1718706290
