On Tue, 20 Feb 2024 08:36:29 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments resolutions.
>
> src/hotspot/cpu/x86/x86.ad line 4120:
>
>> 4118: BasicType elem_bt =
> Hi All,
>
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and
> AVX512 features.
>
> Following is the summary of changes:-
>
> 1) Intrinsify sub-word gather using hybrid algorithm which initially
> partially unrolls scalar loop to accumulates values from gather
On Tue, 20 Feb 2024 08:04:27 GMT, Emanuel Peter wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584:
>>
>>> 1582: Label *larr[] = {, , , };
>>> 1583: for (int i = 0; i < 4; i++) {
>>> 1584: // dst[i] = mask ? src[index[i]] : 0
>>
>> I like these comments a lot!
>>
On Fri, 23 Feb 2024 19:18:22 GMT, Joe Darcy wrote:
> > Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result
> > here. I don't know why the paper says otherwise. Perhaps OpenLibm is not
> > exactly fdlibm.
>
> I've looked a bit over the OpenLibm changelog. They've added a
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
> details the inputs with generate the worst-case
On Sat, 24 Feb 2024 17:15:02 GMT, Eirik Bjørsnøs wrote:
> Since the CSR is already approved, I'll add a question here:
>
> `ZipFile` performs a lot of validation while opening ZIP files, including
> throwning ZipException for invalid entry names or comments. Why handle the
> ZIP file comment
On Sat, 24 Feb 2024 16:57:50 GMT, Eirik Bjørsnøs wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updates based on 1st round of feedback
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 331:
>
>>
On Sat, 24 Feb 2024 18:51:22 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
> Please review this PR which addresses the handling of invalid UTF-8 byte
> sequences in the entry name of a LOC file header and a Zip file comment which
> is returned via ZipFile::getComment.
>
> As part of the change, `ZipFile::getComment` will now return `null` if an
> invalid UTF-8 byte
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote:
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
> `COMPAT` locale data was introduced for applications' migratory purposes
> transitioning to `CLDR`. It is becoming a technical debt and now is the time
> to
In the current version, FMT."v =%d{1}" will call the
StringConcatHelper.prepend(long/byte[]/long) method, which should behave the
same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int), should
not convert int to long
Please review and don't hesitate to critique my approach and
On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen wrote:
> Please review this PR which addresses the handling of invalid UTF-8 byte
> sequences in the entry name of a LOC file header and a Zip file comment which
> is returned via ZipFile::getComment.
>
> As part of the change,
On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen wrote:
> Please review this PR which addresses the handling of invalid UTF-8 byte
> sequences in the entry name of a LOC file header and a Zip file comment which
> is returned via ZipFile::getComment.
>
> As part of the change,
> Please review this PR which proposes that we officially deprecate the
> following four methods in the `java.util.zip` package:
>
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
>
> Since these legacy methods return `int`, they
On Sat, 24 Feb 2024 11:45:46 GMT, Jaikiran Pai wrote:
> This is similar to what other test libraries usually report for such failures.
But in the case of a non-empty `msg` you would not see the actual values any
more which I think could be helpful in a lot of cases...
-
PR
Please review this PR which addresses the handling of invalid UTF-8 byte
sequences in the entry name of a LOC file header and a Zip file comment which
is returned via ZipFile::getComment.
As part of the change, `ZipFile::getComment` will now return `null` if an
invalid UTF-8 byte sequence is
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote:
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
> `COMPAT` locale data was introduced for applications' migratory purposes
> transitioning to `CLDR`. It is becoming a technical debt and now is the time
> to
18 matches
Mail list logo
