Hi, I did some testing where one gatherer (doNothingReturnTrue) does not handle the downStream.push(element) returning false correctly. The stream processing is terminated in one case and not in the two other.Especially see the difference between output from handling «efgh» and «EFGH» below. Is
On Thu, 30 Nov 2023 11:12:36 GMT, Sergey Tsypanov wrote:
>> It looks like we can skip copying of `byte[]` in
>> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in
>> `java.io`.
>>
>> See comment by @vlsi in
>>
On Thu, 30 Nov 2023 11:12:36 GMT, Sergey Tsypanov wrote:
>> It looks like we can skip copying of `byte[]` in
>> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in
>> `java.io`.
>>
>> See comment by @vlsi in
>>
On Fri, 1 Dec 2023 23:21:35 GMT, Brian Burkhalter wrote:
>> The case of `Channels.newOutputStream(AsynchronousByteChannel)` could be
>> handled by changing the return value of that method. For example,
>> `sun.nio.ch.Streams` could have a method `OutputStream
>> of(AsynchronousByteChannel)`
On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik wrote:
> Description of problem and propsed fix from @plummercj
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
>
> process.top.app=top
> process.top.args=-l 1
>
> So top is run with the "-l 1" args, causing it to do one
On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik wrote:
> Description of problem and propsed fix from @plummercj
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
>
> process.top.app=top
> process.top.args=-l 1
>
> So top is run with the "-l 1" args, causing it to do one
On Fri, 1 Dec 2023 20:01:42 GMT, Leonid Mesnik wrote:
> Technically, the volatile is not enough to avoid racy writing into exitValue.
> However, it doesn't affect logic.
Agreed.
-
PR Comment: https://git.openjdk.org/jdk/pull/16919#issuecomment-1836981670
On Fri, 1 Dec 2023 22:26:51 GMT, Brian Burkhalter wrote:
>> I see the problem that unless we have an explicit whitelist, we do open the
>> risk of accidentially adding another wrapper stream in future to the JDK
>> somewhere and forget to add it to the blacklist. So for safety, I would
>>
On Fri, 1 Dec 2023 22:16:33 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/text/MessageFormat.java line 299:
>>
>>> 297: * the string produced by a {@code ChoiceFormat} in {@code
>>> MessageFormat} is
>>> 298: * treated as special; occurrences of '{' are used to indicate
>>>
> Please review this PR which updates an incorrect code example in
> _java/text/ChoiceFormat_.
>
> ChoiceFormat (and MessageFormat) provide an example of how to produce a
> pattern that supports singular and plural forms. The ChoiceFormat example is
> incorrect, as recursive MessageFormats
On Fri, 1 Dec 2023 13:46:59 GMT, Markus KARG wrote:
>> @bplb You did it right. The reason it works is because the
>> ChannelOutputStream is in the "sun." package and not the "java." package.
>> That is not the case for Channels.newOutputStream(AsynchronousByteChannel
>> ch) as that wrapper
On Fri, 1 Dec 2023 13:33:01 GMT, Markus KARG wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8321053: Trust non-FilterOutputStreams in "java." packages
>
>
On Fri, 1 Dec 2023 21:24:47 GMT, Naoto Sato wrote:
>> This is the fix to JLine, which makes it on par with the built-in Console
>> fix ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the
On Fri, 1 Dec 2023 22:06:14 GMT, Viktor Klang wrote:
>> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of
>> GathererTest.
>>
>> Fixes a test ordering issue in testMapConcurrentAPIandContract().
>>
>> Adding increased maxOutputSize for Gatherer-related tests to improve
On Fri, 1 Dec 2023 21:53:06 GMT, Justin Lu wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> clarify limitations
>
> src/java.base/share/classes/java/text/MessageFormat.java line 299:
>
>> 297: * the string produced
> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of
> GathererTest.
>
> Fixes a test ordering issue in testMapConcurrentAPIandContract().
>
> Adding increased maxOutputSize for Gatherer-related tests to improve
> debuggability.
>
> Lowering the composition threshold of
On Fri, 1 Dec 2023 21:51:14 GMT, Justin Lu wrote:
>> Please review this PR which updates an incorrect code example in
>> _java/text/ChoiceFormat_.
>>
>> ChoiceFormat (and MessageFormat) provide an example of how to produce a
>> pattern that supports singular and plural forms. The ChoiceFormat
> Please review this PR which updates an incorrect code example in
> _java/text/ChoiceFormat_.
>
> ChoiceFormat (and MessageFormat) provide an example of how to produce a
> pattern that supports singular and plural forms. The ChoiceFormat example is
> incorrect, as recursive MessageFormats
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982)
> which overrides and provides an implementation of `toString()` in
> _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
Justin Lu has updated the pull request incrementally with one additional
> This is the fix to JLine, which makes it on par with the built-in Console fix
> ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
moved instance fields at the top of the
On Fri, 1 Dec 2023 19:40:39 GMT, Iris Clark wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> moved instance fields at the top of the class
>
>
On Fri, 1 Dec 2023 12:44:17 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in
On Fri, 1 Dec 2023 18:24:48 GMT, Naoto Sato wrote:
> This is the fix to JLine, which makes it on par with the built-in Console fix
> ([JDK-8320798](https://bugs.openjdk.org/browse/JDK-8320798)).
Marked as reviewed by iris (Reviewer).
On Wed, 15 Nov 2023 20:10:53 GMT, Eirik Bjorsnos wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982)
> which overrides and provides an implementation of `toString()` in
> _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
Justin Lu has updated the pull request incrementally with one additional
On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy wrote:
>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update symbol files to JDK 22 b26.
looks good to me
-
Marked
On Fri, 1 Dec 2023 08:49:34 GMT, Alan Bateman wrote:
>> Thanks Jai, that makes sense. Replaced full path with just the base name in
>> latest commit.
>
> I think the second paragraph of the method description is problematic.
> Documenting the representation and then saying it is subject to
On Fri, 24 Nov 2023 18:30:17 GMT, Erik Österlund wrote:
>> The current logic for closing memory in panama today is susceptible to live
>> lock if we have a closing thread that wants to close the memory in a loop
>> that keeps failing, and a bunch of accessing threads that want to perform
>>
On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato wrote:
> Removing the unnecessary array assignments.
This pull request has now been integrated.
Changeset: f6be7fdf
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk/commit/f6be7fdf22eede767a0ac29b4f1cb770cfdc0b0f
Stats: 8 lines in
On Thu, 30 Nov 2023 17:39:30 GMT, Naoto Sato wrote:
>> It is best practice to zero out the underlying buffer after use.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove ensureOpen()
Thanks all for the reviews!
On Tue, 28 Nov 2023 19:12:50 GMT, Naoto Sato wrote:
> It is best practice to zero out the underlying buffer after use.
This pull request has now been integrated.
Changeset: d5685629
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk/commit/d568562966e9a2020704eee3d67b8a106f647d9c
Renames GatherersTest to BuiltInGatherersTest for easier deduplication of
GathererTest.
Fixes a test ordering issue in testMapConcurrentAPIandContract().
Adding increased maxOutputSize for Gatherer-related tests to improve
debuggability.
Lowering the composition threshold of
On Fri, 1 Dec 2023 17:00:48 GMT, Viktor Klang wrote:
> Renames GatherersTest to BuiltInGatherersTest for easier deduplication of
> GathererTest.
>
> Fixes a test ordering issue in testMapConcurrentAPIandContract().
>
> Adding increased maxOutputSize for Gatherer-related tests to improve
>
On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik wrote:
> Description of problem and propsed fix from @plummercj
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
>
> process.top.app=top
> process.top.args=-l 1
>
> So top is run with the "-l 1" args, causing it to do one
On Tue, Nov 28, 2023 at 6:16 PM Alan Bateman
wrote:
> This is a JDK 1.1 era mistake. It would a source incompatible change to
> "remove" the constants. It would require corpus searches to gauge the
> impact.
Alan,
I've tried to assess the impact by using Github's Code Search. As far as I
can
On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley wrote:
>> Xiaohong Gong 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 ten additional
>> commits
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Fri, 1 Dec 2023 16:35:31 GMT, Magnus Ihse Bursie wrote:
>> Yes. It still failed.
>
> You need to expand this logic to cover more instances. See e.g. lib-ffi.m4
> for inspiration.
>
> Basic flow:
> * if user has specified libsleef root with argument, check both lib/ and
> lib64/ under that
On Fri, 1 Dec 2023 10:02:35 GMT, Andrew Haley wrote:
>> Did you try to find the libsleef by passing `--with-libsleef=` ? Currently
>> `--with-libsleef=` can only work for people manually built from sleef source
>> code.
>
> Yes. It still failed.
You need to expand this logic to cover more
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Thu, 30 Nov 2023 08:00:12 GMT, Damon Fenacci wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use byte off branches in char_array_compress
>> Verified by manual tests with "-XX:AVX3Threshold=0"
>> And test in
On Thu, 30 Nov 2023 15:51:46 GMT, Roger Riggs wrote:
>> Strings, after construction, are immutable but may be constructed from
>> mutable arrays of bytes, characters, or integers.
>> The string constructors should guard against the effects of mutating the
>> arrays during construction that
On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley wrote:
>> Xiaohong Gong 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 ten additional
>> commits
On Fri, 1 Dec 2023 14:30:12 GMT, Christian Stein wrote:
>> A trivial fix to ProblemList java/util/stream/GatherersTest.java.
>
> Seems to be a different issue with "linux-x86" (32-bit host) and
> `GathererTest::testMassivelyComposedGatherers`.
>
>
On Wed, 29 Nov 2023 22:55:41 GMT, Brian Burkhalter wrote:
> > As Alan pointed out, it is a bug (actually even a security risk), so BAIS
> > should get fixed, too.
>
> I am going to file an issue on this.
Thank you, I just planned to fix this today when I saw your existing PR!
-
On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/stream/GatherersTest.java.
Seems to be a different issue with "linux-x86" (32-bit host) and
`GathererTest::testMassivelyComposedGatherers`.
On Fri, 1 Dec 2023 14:05:37 GMT, Bernd wrote:
>> Did you review if all Java.* streams are safe?
>>
>> There are a few stream adapters in sun.nio.ch, which would benefit this
>> optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I
>> guess that’s not safe, so the
On Fri, 1 Dec 2023 14:05:37 GMT, Bernd wrote:
>> Did you review if all Java.* streams are safe?
>>
>> There are a few stream adapters in sun.nio.ch, which would benefit this
>> optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I
>> guess that’s not safe, so the
On Thu, 30 Nov 2023 09:36:01 GMT, Bernd wrote:
>> Sergey Tsypanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8320971: Trust any OutputStream from java.*
>
> Did you review if all Java.* streams are safe?
>
> There are a few stream
On Fri, 1 Dec 2023 04:01:42 GMT, jmehrens wrote:
>> I might have done this incorrectly, but with this version of the above
>> `wolf` I do not see any corruption:
>>
>> java.nio.channels.WritableByteChannel wolf =
>> new java.nio.channels.WritableByteChannel() {
>>
> Classfile API is an internal library under package `jdk.internal.classfile`
> in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it
> into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>
> This PR
On Fri, 1 Dec 2023 13:46:14 GMT, Matthias Baesken wrote:
> On Windows we recently run into this error rather often in the test
> LdapPoolTimeoutTest.java :
>
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root
> exception is java.net.ConnectException: Connection timed out:
On Windows we recently run into this error rather often in the test
LdapPoolTimeoutTest.java :
MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception
is java.net.ConnectException: Connection timed out: no further information]
MSG: Connect timed out
MSG: Timeout exceeded
On Thu, 30 Nov 2023 23:30:20 GMT, Brian Burkhalter wrote:
>> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of
>> `BAIS.transferTo` only if the target stream is in the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Wed, 29 Nov 2023 08:46:46 GMT, Per Minborg wrote:
>> This is explicit list of supported class file versions, so I don't see any
>> other way.
>
> Would it not be possible to expose an immutable `Map` that
> maps from Java version to major class version?
This is actually out of scope of
On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee wrote:
> Need to use `jlong_to_ptr` instead of raw cast.
>
> I've also fixed another latent issue in `CLayouts` where we were initializing
> `C_LONG_LONG` with the `long` layout. This was resulting in a class cast
> exception when running the
On Thu, 30 Nov 2023 17:39:30 GMT, Naoto Sato wrote:
>> It is best practice to zero out the underlying buffer after use.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove ensureOpen()
Marked as reviewed by mbaesken
On Fri, 1 Dec 2023 12:44:17 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in
On Fri, 1 Dec 2023 12:09:14 GMT, Stefan Karlsson wrote:
>> Hello Stefan, this is just for a tiny optimization to prevent multiple reads
>> (in the same thread) on the `volatile` field `processExitCode` in this
>> method.
>
> I don't think such an optimization is needed here. This is not
>
> Can I please get a review for this change to the test library's
> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
> from the `getExitValue()` call?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this
> method logs:
>
>
>
On Fri, 1 Dec 2023 11:14:04 GMT, Jaikiran Pai wrote:
>> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
>>
>>> 148: @Override
>>> 149: public int getExitValue() {
>>> 150: Integer exitCode = this.processExitCode;
>>
>> Do we really need the local `exitCode` variable?
On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee wrote:
> Need to use `jlong_to_ptr` instead of raw cast.
>
> I've also fixed another latent issue in `CLayouts` where we were initializing
> `C_LONG_LONG` with the `long` layout. This was resulting in a class cast
> exception when running the
On Fri, 1 Dec 2023 11:22:33 GMT, Pavel Rappo wrote:
>> Please review this PR to correctly rename "Unnamed Class" to "Implicitly
>> Declared Class", not "Implicit Class".
>>
>> Renaming is fixed where it affects documentation or the end-user. Renaming
>> is not fixed where it only affects
On Thu, 30 Nov 2023 15:00:00 GMT, Pavel Rappo wrote:
> Please review this PR to correctly rename "Unnamed Class" to "Implicitly
> Declared Class", not "Implicit Class".
>
> Renaming is fixed where it affects documentation or the end-user. Renaming is
> not fixed where it only affects code:
On Fri, 1 Dec 2023 11:07:06 GMT, Stefan Karlsson wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in
On Fri, 1 Dec 2023 11:10:16 GMT, Stefan Karlsson wrote:
>> test/lib/jdk/test/lib/process/OutputBuffer.java line 158:
>>
>>> 156: boolean aborted = true;
>>> 157: try {
>>> 158: this.processExitCode = exitCode = p.waitFor();
>>
>> According to the `waitFor`
> Can I please get a review for this change to the test library's
> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
> from the `getExitValue()` call?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this
> method logs:
>
>
>
On Thu, 30 Nov 2023 16:11:01 GMT, Jim Laskey wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove a comment typo introduced in JEP 445
>
> LGTM
@JimLaskey please re-review this PR due to a newly pushed
On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/stream/GatherersTest.java.
Off by one "s"?
Or does `java/util/stream/GathererTest` (without "s") fail in addition?
> Please review this PR to correctly rename "Unnamed Class" to "Implicitly
> Declared Class", not "Implicit Class".
>
> Renaming is fixed where it affects documentation or the end-user. Renaming is
> not fixed where it only affects code: it's perfectly okay to derive an
> internal element name
On Fri, 1 Dec 2023 11:09:30 GMT, Stefan Karlsson wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in
On Fri, 1 Dec 2023 09:48:23 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change to the test library's
> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
> from the `getExitValue()` call?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8321163,
On Wed, 8 Nov 2023 19:59:34 GMT, Lance Andersen wrote:
> Please review this PR which enhances the existing CEN header validation
> checking to ensure that the
> size of the CEN Header + name length + comment length + extra length do not
> exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10,
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Fri, 1 Dec 2023 01:13:37 GMT, Xiaohong Gong wrote:
>> make/autoconf/lib-sleef.m4 line 56:
>>
>>> 54: AC_MSG_CHECKING([for the specified LIBSLEEF])
>>> 55: if test -e ${with_libsleef}/lib/libsleef.so &&
>>> 56:test -e ${with_libsleef}/include/sleef.h; then
>>
>>
On Fri, 1 Dec 2023 01:19:12 GMT, Xiaohong Gong wrote:
> > Not having a build time dependency on libsleef means you cannot really
> > verify that the functions you want to call are correct, but maybe you feel
> > secure that they will never change?
>
> I'm not sure. The main reason that we add
On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls wrote:
> RMI Connections (in general) should use a timeout on the Socket connect call
> by default.
>
> JMX connections use RMI and some connection failures never terminate. The
> hang described in 8316649 is hard to reproduce manually: the
On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls wrote:
> RMI Connections (in general) should use a timeout on the Socket connect call
> by default.
>
> JMX connections use RMI and some connection failures never terminate. The
> hang described in 8316649 is hard to reproduce manually: the
On Fri, 1 Dec 2023 09:59:58 GMT, Andrew Haley wrote:
> Not having a build time dependency on libsleef means you cannot really verify
> that the functions you want to call are correct, but maybe you feel secure
> that they will never change?
We can still have SLEEF tests, but they will require
On Thu, 30 Nov 2023 14:50:24 GMT, Andrew Haley wrote:
>> Do this, but with the name vect_math.S. Don't use SLEEF headers in the
>> build. I think you can do this with no build-time dependency on SLEEF at all
>> if you load the library lazily at runtime.
>>
>>
On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik wrote:
> Description of problem and propsed fix from @plummercj
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
>
> process.top.app=top
> process.top.args=-l 1
>
> So top is run with the "-l 1" args, causing it to do one
Can I please get a review for this change to the test library's
`OutputAnalyzer` class, which proposes to remove some unnecessary logging from
the `getExitValue()` call?
As noted in https://bugs.openjdk.org/browse/JDK-8321163, right now this method
logs:
[2023-11-24T11:47:54.557561Z] Waiting
On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy wrote:
>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update symbol files to JDK 22 b26.
Good good. I assume you'll bump the
On Thu, 30 Nov 2023 21:08:35 GMT, Justin Lu wrote:
>> Hello Justin,
>>
>>> I am not sure if you have a preference one way or another regarding
>>> providing the full path versus just the file name, but I can switch the
>>> full path for just the file name if need be.
>>
>> My opinion is that
> Currently the vector floating-point math APIs like
> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
> which causes large performance gap on AArch64. Note that those APIs are
> optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1].
> To close
86 matches
Mail list logo
