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 acceptin
> 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 W
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/L
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/Lo
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/Lo
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 integrati
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:Use
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:Use
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
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 u
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 lib
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.
>
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
>> par
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
> 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 (
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 u
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 u
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 .
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 l
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.ope
> 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 Un
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 simpl
> 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
23 matches
Mail list logo
