On Tue, 16 Jan 2024 16:38:34 GMT, Glavo wrote:
>> Using `ByteArrayLittleEndian` is simpler and faster.
>>
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>>
>>
>> Benchmark (size) Mode Cnt Score Error
>> Units
>> - ZipFileOpen.openCloseZipFile 512
On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs wrote:
>> `GZIPInputStream`, when looking for a concatenated stream, relies on what
>> the underlying `InputStream` says is how many bytes are `available()`. But
>> this is inappropriate because `InputStream.available()` is just an estimate
>> and
On Wed, 28 Feb 2024 06:12:17 GMT, Guoxiong Li wrote:
> So large patch. In order to easy to review, it is good to separate such large
> patch into several patches in the future.
I was doing that in prior related changes (see the subtasks of JDK-8324799).
But reviewers requested I batch up
the
On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote:
> The new test JmodExcludedFiles.java checks that no debug symbol files are
> contained in the jmod files. It does not take into account that with
> configure option --with-external-symbols-in-bundles=public we want to have
> stripped p
On Tue, 27 Feb 2024 16:48:05 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
>> compiler.rtm.locking.TestRTMTot
On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote:
> Please review this change that renames some test .h files to .hpp. These
> files contain C++ code and should be named accordingly. Some of them contain
> uses of NULL, which we change to nullptr.
>
> The renamed files are:
>
> test/hotspo
> 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 observed
On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote:
> Please review this change that renames some test .h files to .hpp. These
> files contain C++ code and should be named accordingly. Some of them contain
> uses of NULL, which we change to nullptr.
>
> The renamed files are:
>
> test/hotspo
On Fri, 3 Nov 2023 14:03:02 GMT, Chen Liang wrote:
> Please review a patch that migrates `Class::getEnclosingMethod` and
> `Class::getEnclosingConstructor`'s descriptor parsing from old generic
> utilities to more simple utilities from java.lang.invoke implementation. This
> will help migrate
Please review this change that renames some test .h files to .hpp. These
files contain C++ code and should be named accordingly. Some of them contain
uses of NULL, which we change to nullptr.
The renamed files are:
test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
test/hotspot/jtreg/vmTestbase/
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)
On Tue, 27 Feb 2024 20:01:20 GMT, Joe Darcy wrote:
>> What is the issue with this? Is there a different way to set a timeout? The
>> test tests that format does not take a long time to run so I would like to
>> have a timeout
>
>> What is the issue with this? Is there a different way to set a t
On Tue, 27 Feb 2024 02:47:13 GMT, Jatin Bhateja wrote:
>> 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
>> p
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 27 Feb 2024 11:20:11 GMT, Raffaello Giulietti
wrote:
> There are no libraries that have worse errors than OpenLibm, so I'm wondering
> what these values are good for?
When I was working on updating the worst-case tests for Math, I would check the
input values in Math.foo() and StrictM
On Tue, 27 Feb 2024 11:20:01 GMT, Raffaello Giulietti
wrote:
> I can't find this one on the paper.
Good catch; must have been a cut and paste error on my part.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504993038
On Fri, 16 Feb 2024 23:43:15 GMT, Srinivas Vamsi Parasa
wrote:
>> Hi Vamsi (@vamsi-parasa),
>>
>> My fault, there was an incorrect version of ArraysSortNew.java. Methods, of
>> course, should be
>>
>> @Benchmark
>> public void sort() {
>> Arrays.sort(b);
>> }
>>
>> @Benchmark
>> public v
On Tue, 27 Feb 2024 19:46:27 GMT, Chad Rakoczy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>> [JDK
On Tue, 27 Feb 2024 20:01:30 GMT, Eirik Bjørsnøs wrote:
> After some offline discussion about the redundant text, we decided to keep to
> the new method description text, but reduce the `@deprecated` note to simply
> refer to the replacement method:
>
> ```
> /**
> * Returns the total number
On Tue, 27 Feb 2024 19:53:23 GMT, Joe Darcy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>> [JDK-82
On Tue, 27 Feb 2024 19:59:08 GMT, Eirik Bjørsnøs wrote:
>> 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.ge
On Tue, 27 Feb 2024 19:21:13 GMT, Chad Rakoczy wrote:
> What is the issue with this? Is there a different way to set a timeout? The
> test tests that format does not take a long time to run so I would like to
> have a timeout
Hard-coded timeout in a test are generally considered harmful as the
On Tue, 27 Feb 2024 19:46:27 GMT, Chad Rakoczy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>> [JDK
> 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 c
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-829
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-829
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-829
On Tue, 27 Feb 2024 19:20:36 GMT, Raffaello Giulietti
wrote:
> I guess the title should read "8326718: Test java/util/Formatter/Padding.java
> does not timeout on large inputs _after_ JDK-8299677"
The test should timeout/fail before the fix in JDK-8299677 and pass after
-
PR Comm
On Tue, 27 Feb 2024 19:13:10 GMT, Alan Bateman wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>> [JDK
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-829
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-829
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
> [JDK-829
[JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
with Formatter.format taking a long time when there is a lot of padding. This
test runs Formatter.format with very large padding. Test fails before
[JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and pass
On Tue, 27 Feb 2024 11:24:08 GMT, Magnus Ihse Bursie wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing review comments
>
> This looks good from a build perspective. Actually, it looks great! :) I'm
> happy
On Tue, 27 Feb 2024 16:48:05 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
>> compiler.rtm.locking.TestRTMTot
On Mon, 26 Feb 2024 01:17:23 GMT, Jaikiran Pai wrote:
> Hello Christoph, yes that looks fine to me.
I adjusted it to the given suggestion.
-
PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1967070481
> 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
> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:🔒 expected 0 to equal 1
>at jdk.test.
On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote:
> Please help review this trivial change. This was branched from
> https://github.com/openjdk/jdk/pull/18013, based on discussion with
> @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks
This pull request has now been
> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
> module summary so that it is consistent with the use of "ZIP".
>
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java
> has been updated to point to the higher level location of the PKWARE
On Tue, 27 Feb 2024 16:12:03 GMT, Lance Andersen wrote:
>> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
>> module summary so that it is consistent with the use of "ZIP".
>>
>> In addition,
>> open/src/java.base/share/classes/java/util/zip/package-info.java has be
On Tue, 27 Feb 2024 15:08:11 GMT, Eirik Bjørsnøs wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address initial feedback for JDK-8326687
>
> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 54
On Tue, 27 Feb 2024 07:29:46 GMT, Daniel Jeliński wrote:
>> Please help review this trivial change. This was branched from
>> https://github.com/openjdk/jdk/pull/18013, based on discussion with
>> @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks
>
> LGTM
@djelinski @Rog
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory `jm
On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote:
> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
> module summary so that it is consistent with the use of "ZIP".
>
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java
> has been up
On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote:
> Please help review this trivial change. This was branched from
> https://github.com/openjdk/jdk/pull/18013, based on discussion with
> @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks
Marked as reviewed by rriggs (
On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote:
> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
> module summary so that it is consistent with the use of "ZIP".
>
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java
> has been up
> In this PR I updated the tests to use the newer
> ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child
> processes.
Matthew Donovan has updated the pull request incrementally with one additional
commit since the last revision:
removed unused import statement
-
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote:
> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
> module summary so that it is consistent with the use of "ZIP".
>
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java
> has been up
On Tue, 27 Feb 2024 10:30:44 GMT, Viktor Klang wrote:
> As an intermediate fix to the test, switching to explicit usage of an
> ExecutorService seems to do the trick to make this test reliably pass.
>
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
> ForkJoinPool,
On Tue, 27 Feb 2024 11:44:31 GMT, Daniel Jeliński wrote:
> FWIW, when I added -lstdc++ before both -static-libstdc++ and replaced LDCXX
> with LD, the code compiled and linked just fine.
Both GCC and G++ call the same linker, and the parameter differences are well
documented. It's only a matter
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie wrote:
> > can we get rid of LDCXX?
>
> Yeah, that is something I plan to look into. Linking C++ object files with
> gcc will fail; and it might be that linking pure C with g++ might be
> problematic. If this is the case, I hope we can at le
On Tue, 27 Feb 2024 00:24:08 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 r
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
> specific argument to SetupNativeCompilation, LANG := C++ or LANG
On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters wrote:
> All those new parameters to SetupNativeCompilation, were they always there
> and the comments about them were just missing from the documentation about
> the function?
Yep. The toolchain definition was a way to "package" multiple argumen
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
> sp
On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters wrote:
> can we get rid of LDCXX?
Yeah, that is something I plan to look into. Linking C++ object files with gcc
will fail; and it might be that linking pure C with g++ might be problematic.
If this is the case, I hope we can at least determine
On Tue, 27 Feb 2024 06:13:08 GMT, Joe Darcy wrote:
>> 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
>>
On Tue, 27 Feb 2024 02:47:13 GMT, Jatin Bhateja wrote:
>> 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
>> p
On Tue, 27 Feb 2024 10:25:19 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comment resolutions.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1672:
>
>> 1670: Label GATHER8_
On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang wrote:
> More aggressively breaking chains in order to prevent nodes promoted to older
> generations standing in the way for collecting younger nodes. I decided that
> it was most efficient to add this logic to the else-branch of updating the
> fi
As an intermediate fix to the test, switching to explicit usage of an
ExecutorService seems to do the trick to make this test reliably pass.
With that said, this test (CHM::ToArray.java) seems to trigger an issue in
ForkJoinPool, so that would need to be fixed separately.
Tagging @DougLea as an
Task providing Class-File API transition to Second Preview.
-
Commit messages:
- 8326744: Class-File API transition to Second Preview
Changes: https://git.openjdk.org/jdk/pull/18021/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18021&range=00
Issue: https://bugs.openjdk.
On Mon, 26 Feb 2024 20:46:01 GMT, Eirik Bjørsnøs wrote:
>> 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.ge
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
On Tue, 27 Feb 2024 08:07:38 GMT, Daniel Jeliński wrote:
> can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is
> `gcc`; I searched for the differences, and the only thing I could find is
> that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could
> explicitl
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
68 matches
Mail list logo
