On Mon, 6 Feb 2023 17:53:24 GMT, Joe Darcy wrote:
> Therefore, I think these tests should be included in the repository, but not
> run all the time, which led me to declare them as a manual jtreg test.
Manual tests are run at each release. There are a couple of examples in the
repo with tests
On Mon, 6 Feb 2023 17:53:24 GMT, Joe Darcy wrote:
> Therefore, I think these tests should be included in the repository, but not
> run all the time, which led me to declare them as a manual jtreg test.
-
PR: https://git.openjdk.org/jdk/pull/12430
The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests.
We'd like to convert these JUnit in the main line in advance of other updates
to these tests in 21. The changes are mostly mechanical and trivial:
- BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
-
On Thu, 2 Feb 2023 10:06:23 GMT, Alan Bateman wrote:
>>> level:1, strategy: 0, dowrap: false
>>> is finished: false
>>
>> Thanks for checking that. So "is finished: false" is telling us that not all
>> of the input was compressed. So I think the right thing is to do the
On Thu, 2 Feb 2023 10:06:23 GMT, Alan Bateman wrote:
>>> level:1, strategy: 0, dowrap: false
>>> is finished: false
>>
>> Thanks for checking that. So "is finished: false" is telling us that not all
>> of the input was compressed. So I think the right thing is to do the
On Mon, 6 Feb 2023 11:37:41 GMT, Raffaello Giulietti
wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct overflow limit in regression test.
>
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 938:
>
>>
On Tue, 7 Feb 2023 00:12:21 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
On Mon, 6 Feb 2023 15:35:30 GMT, Roger Riggs wrote:
> Please add @bug 8301737
>
> It is not going to be obvious why a larger code cashe is needed (and only for
> aarch64).
>
The error message in the .jtr file is `java.rmi.NoSuchObjectException: no such
object in table`, which corresponding
On Mon, 6 Feb 2023 17:39:42 GMT, Paul Sandoz wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add smaller array size for benchmark tests
>
> I think it would be useful to adjust the naming and comments of some
On Mon, 6 Feb 2023 09:46:15 GMT, Tagir F. Valeev wrote:
>> clamp() methods added to Math and StrictMath
>>
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
>> value and safely clamps it to an `int` range. Other overloads work with a
>> particular type (long, float
On Mon, 6 Feb 2023 09:46:15 GMT, Tagir F. Valeev wrote:
>> clamp() methods added to Math and StrictMath
>>
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
>> value and safely clamps it to an `int` range. Other overloads work with a
>> particular type (long, float
On Tue, 7 Feb 2023 00:12:21 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
> Added code for Base64 acceleration (encode and decode) which will accelerate
> ~4x for AVX2 platforms.
>
> Encode performance:
> **Old:**
>
> Benchmark (maxNumBytes) Mode Cnt Score Error
> Units
> Base64Encode.testBase64Encode 1024 thrpt3
On Fri, 3 Feb 2023 18:25:17 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
> The example code in ObjectInputFilter for the FilterInThread filter factory
> does not do what is intended and is poorly described. Clarifies that the
> JVM-wide filter and the thread local filter are merged and will reject
> classes that are otherwise not accepted or rejected. If a stream
On Mon, 6 Feb 2023 21:55:26 GMT, Joe Darcy wrote:
>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 874:
>>
>>> 872: // lx = *( (((*(unsigned*))>>29)) + (unsigned*));
>>> 873: // lx = (((*(unsigned*))>>29)) + (unsigned*) ;
>>> 874: lx = __LO(x);
>>
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs transliteration port:
>
>
> $ diff -w Hyperbolic.c
On Mon, 6 Feb 2023 11:34:40 GMT, Raffaello Giulietti
wrote:
>> Joe Darcy has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Two more spacing fixes.
>> - Implement spacing improvements from code review comments.
>
>
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs transliteration port:
>
>
> $ diff -w Hyperbolic.c
On Mon, 6 Feb 2023 08:33:37 GMT, Andrey Turbanov wrote:
>> Joe Darcy has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Two more spacing fixes.
>> - Implement spacing improvements from code review comments.
>
>
The example code in ObjectInputFilter for the FilterInThread filter factory
does not do what is intended and is poorly described. Clarifies that the
JVM-wide filter and the thread local filter are merged and will reject classes
that are otherwise not accepted or rejected. If a stream specific
> This is an approach to adding a flag to jlink that will allow --compress to
> take the same types of arguments as jmod, thus bringing the two into
> alignment. This likely requires a CSR and a discussion on whether we should
> deprecate or simply remove the original numeric compression
> Added code for Base64 acceleration (encode and decode) which will accelerate
> ~4x for AVX2 platforms.
>
> Encode performance:
> **Old:**
>
> Benchmark (maxNumBytes) Mode Cnt Score Error
> Units
> Base64Encode.testBase64Encode 1024 thrpt3
On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version
On Mon, 6 Feb 2023 09:18:35 GMT, Alan Bateman wrote:
> Manual tests are the tests of last resort :-) This test may be useful for the
> current transliteration work but it's not clear how this manual test would be
> run by someone tasked with running the manual tests. Right now, it looks like
On Fri, 3 Feb 2023 07:13:10 GMT, Xiaohong Gong wrote:
>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the
> Added code for Base64 acceleration (encode and decode) which will accelerate
> ~4x for AVX2 platforms.
>
> Encode performance:
> **Old:**
>
> Benchmark (maxNumBytes) Mode Cnt Score Error
> Units
> Base64Encode.testBase64Encode 1024 thrpt3
On Mon, 16 Jan 2023 11:44:36 GMT, Eirik Bjorsnos wrote:
> This PR adds test coverage for pending block files in signed JAR files
>
> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes
> before the corresponding signature file [SF] in the JAR.
>
>
Hi Andrey,
Instead, perhaps replace (carefully) the remaining uses in the JDK.
Developers should be using the correct APIs and not reading deprecated
javadoc.
Regards, Roger
On 2/6/23 11:41 AM, Andrey Turbanov wrote:
Hello.
I've noticed that method 'long java.util.Date.parse(String)'
On Mon, 6 Feb 2023 08:19:36 GMT, Alan Bateman wrote:
> @jddarcy Are you planning a GC of unused functions in StrictMath.c too? (for
> this PR I'm wondering about Java_java_lang_StrictMath_expm1).
Yes, once the port is done, I'll remove all the remaining FDLIBM C files. There
are dependencies
Hello.
I've noticed that method 'long java.util.Date.parse(String)' doesn't
have a reference to IllegalArgumentException in its javadoc.
https://docs.oracle.com/javase/7/docs/api/java/util/Date.html#parse(java.lang.String)
But this exception is thrown in implementation.
I know that this method is
On Mon, 6 Feb 2023 15:56:09 GMT, Claes Redestad wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Spelling fix in test data for non-ascii latin1 string
>
>
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this
On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8301834?
>
> Some classes in `java.nio` package are generated from template files, during
> the build. The template
On Mon, 6 Feb 2023 15:14:37 GMT, Eirik Bjorsnos wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java
On Tue, 17 Jan 2023 18:54:13 GMT, Eirik Bjorsnos wrote:
>> This PR adds test coverage for pending block files in signed JAR files
>>
>> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes
>> before the corresponding signature file [SF] in the JAR.
>>
>>
On Mon, 6 Feb 2023 11:44:07 GMT, SUN Guoyun wrote:
>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC
>> to be triggered early, then causing this test failed on LoongArch64
>> architecture.
>>
>> This PR fix the issue, Please help review it.
>>
>>
On Tue, 31 Jan 2023 10:45:07 GMT, Viktor Klang wrote:
> The proposed fix by @DougLea ensures that the state transition into waiting
> is retried in the cases where a previous waiter isn't making progress and a
> new waiter goes into waiting.
This pull request has now been integrated.
On Sun, 5 Feb 2023 19:04:24 GMT, Alan Bateman wrote:
> Are you planning to include benchmark results to go with this change?
>
> It should be okay to change readFullyAt to use pread, and ReadFile with an OV
> with the position. The latter has a side effect that it changes the file
> pointer
On Mon, 6 Feb 2023 15:17:14 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this
On Mon, 6 Feb 2023 12:01:19 GMT, Eirik Bjorsnos wrote:
>> Nice, I have updated the PR such that the new shared secret is replaced with
>> using getBytesNoRepl instead. If there is a performance difference, it seems
>> to hide in the noise.
>>
>> I had expected such a regression to be caught
On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos wrote:
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
>
On Mon, 30 Jan 2023 14:20:58 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Mon, 6 Feb 2023 14:27:36 GMT, Claes Redestad wrote:
>> Interesting. Would be nice to solve this in the JIT!
>>
>> This disabled code got deleted in my last commit, but it seems like you have
>> a good analysis so we can let it go now.
>
> Right. I might have fumbled this experiment a bit,
On Mon, 6 Feb 2023 11:56:22 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/System.java line 2671:
>>
>>> 2669: if (false) {
>>> 2670: // Arrays.mismatch without the range checks (~5%
>>> faster micro getEntryHit)
>>> 2671:
On Sun, 5 Feb 2023 22:13:50 GMT, Claes Redestad wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Mon, 6 Feb 2023 11:47:42 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/System.java line 2668:
>>
>>> 2666: @Override
>>> 2667: public int mismatchUTF8(String str, byte[] b, int
>>> fromIndex, int toIndex) {
>>> 2668: byte[]
After finding a hash match, getEntryPos needs to compare the lookup name up to
the encoded entry name in the CEN. This comparison is done by decoding the
entry name into a String. The names can then be compared using the String API.
This decoding step adds a significat cost to this method.
On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos wrote:
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
>
Thanks, I'd planned to file a bug too.
If you think of any improvements, let me know.
On 2/6/23 8:26 AM, Dr Heinz M. Kabutz wrote:
FWIW, I've also submitted this as a bug report:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8301863
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD
On Fri, 3 Feb 2023 18:37:43 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 18:11:41 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:59:53 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:58:04 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:56:45 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:52:49 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 18:07:27 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:
>>
>>> 344: public static final int MAGIC_NUMBER = 0xCAFEBABE;
>>> 345:
>>> 346: public static final int NOP = 0;
>>
>> Not sure how
On Fri, 3 Feb 2023 17:43:22 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:37:55 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
> This is root pull request with Classfile API implementation, tests and
> benchmarks initial drop into JDK.
>
> Following pull requests consolidating JDK class files parsing, generating,
> and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957))
> will chain to this one.
FWIW, I've also submitted this as a bug report:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8301863
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" -www.javaspecialists.eu
Java Champion -www.javachampions.org
JavaOne Rock Star
On Fri, 3 Feb 2023 17:32:37 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:20:19 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:23:51 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 19:49:44 GMT, Justin King wrote:
> Avoid using `lseek` + `read` in favor of `pread`. For Windows, we can do the
> same thing by using `OVERLAPPED`, as we are in synchronous mode we can use
> `Offset` and `OffsetHigh` to achieve the same thing.
>
> Additionally I updated
On Fri, 3 Feb 2023 17:22:32 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 15:07:30 GMT, Roger Riggs wrote:
> What is the connection between -Xcomp and the fix:
> `-Dsun.net.httpserver.idleInterval=5`? The test does not use httpserver.
> Perhaps jtreg /agent does, but an explanation of the interaction would be
> appreciated.
Please review
On Mon, 6 Feb 2023 11:44:07 GMT, SUN Guoyun wrote:
>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC
>> to be triggered early, then causing this test failed on LoongArch64
>> architecture.
>>
>> This PR fix the issue, Please help review it.
>>
>>
On Mon, 6 Feb 2023 02:46:46 GMT, SUN Guoyun wrote:
>> test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java
>> line 41:
>>
>>> 39: /*
>>> 40: * @test
>>> 41: * @run testng/othervm -Dsun.net.httpserver.idleInterval=5
>>> FilterUROTest
>>
>> This test doesn't seem
On Sun, 5 Feb 2023 03:05:55 GMT, Joe Darcy wrote:
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs
> Hi all,
> When -Xcomp be used, java thread to block for longer, then causing this test
> failed frequently on the AArch64 and LoongArch64 architecture.
>
> This PR fix the issue, Please help review it.
>
> Thanks.
SUN Guoyun has updated the pull request incrementally with one additional
On Sun, 5 Feb 2023 03:05:55 GMT, Joe Darcy wrote:
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs
On Mon, 6 Feb 2023 10:01:49 GMT, Quan Anh Mai wrote:
> Suggestion: Refactor the uncommon cases into separate functions so the
> compiler can have easier time inlining the common path. Thanks
@merykitty this probably needs confirmation from VM folks. I'm pretty sure that
C2 will be capable to
On Mon, 6 Feb 2023 09:46:15 GMT, Tagir F. Valeev wrote:
>> clamp() methods added to Math and StrictMath
>>
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
>> value and safely clamps it to an `int` range. Other overloads work with a
>> particular type (long, float
On Mon, 6 Feb 2023 09:03:48 GMT, Quan Anh Mai wrote:
>> @ExE-Boss I think that immediately following `isNaN` checks give enough hint
>> that we want NaN to be here.
>
> Ah I see, a comment explaining the intention would be helpful here, then
Ok, added some explanatory comments. Hopefully they
> clamp() methods added to Math and StrictMath
>
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
> value and safely clamps it to an `int` range. Other overloads work with a
> particular type (long, float and double). Using similar approach in other
> cases (e.g.
On Sun, 5 Feb 2023 18:14:28 GMT, ExE Boss wrote:
>> Tagir F. Valeev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Typo in doc fixed
>
> src/java.base/share/classes/java/lang/Math.java line 2215:
>
>> 2213: public static int
> clamp() methods added to Math and StrictMath
>
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
> value and safely clamps it to an `int` range. Other overloads work with a
> particular type (long, float and double). Using similar approach in other
> cases (e.g.
Hi Roger,
thanks for your quick response. That does seem to work better.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" -www.javaspecialists.eu
Java Champion -www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz
On Mon, 6 Feb 2023 01:50:55 GMT, Joe Darcy wrote:
> To help add assurances that the main-line port of FDLIBM to Java is working
> correctly, added some long-running manual tests to probe that the
> transliteration port and the corresponding StrictMath method are in agreement
> on a large
On Mon, 6 Feb 2023 08:46:54 GMT, Tagir F. Valeev wrote:
>> That should probably include a comment then.
>
> @ExE-Boss I think that immediately following `isNaN` checks give enough hint
> that we want NaN to be here.
Ah I see, a comment explaining the intention would be helpful here, then
On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8301834?
>
> Some classes in `java.nio` package are generated from template files, during
> the build. The template
On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8301834?
>
> Some classes in `java.nio` package are generated from template files, during
> the build. The template
On Sun, 5 Feb 2023 18:08:47 GMT, ExE Boss wrote:
>> No. I want NaNs to go into this branch
>
> That should probably include a comment then.
@ExE-Boss I think that immediately following `isNaN` checks give enough hint
that we want NaN to be here.
-
PR:
On Mon, 6 Feb 2023 03:25:50 GMT, Quan Anh Mai wrote:
>> No. I want NaNs to go into this branch
>
> @amaembo Should that be `if (!(min <= max))` instead?
@merykitty no. I want `min = +0.0` and `max = -0.0` to go into this branch, so
we can report it. A marginal case when `min` and `max` are
On Sun, 5 Feb 2023 18:13:35 GMT, ExE Boss wrote:
>> Tagir F. Valeev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Typo in doc fixed
>
> src/java.base/share/classes/java/lang/Math.java line 2213:
>
>> 2211: * @since 21
>> 2212:
On Sun, 5 Feb 2023 03:05:55 GMT, Joe Darcy wrote:
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs
On Fri, 3 Feb 2023 21:04:15 GMT, Joe Darcy wrote:
>> Next on the FDLIBM C -> Java port, expm1.
>> Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!
>>
>> For expm1, the C vs transliteration port show the usual kind of differences,
>> beside formatting of the constants, the use of the
On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8301834?
>
> Some classes in `java.nio` package are generated from template files, during
> the build. The template
92 matches
Mail list logo
