On Wed, 10 Jul 2024 05:48:23 GMT, David Holmes wrote:
>> I'm not so sure this is in fact a bug. If we are throwing with a cause, but
>> we can't actually throw and so will do vm_exit, then the exception of
>> interest is the cause not the more generic exception that would otherwise
>> contain
On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Narrow scope of the change.
Redu
On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote:
> Hi all,
> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java`
> doesn't receive jvm options from jtreg.
> I think it's necessory to receive jvm options from jtreg.
> The change has been verified, only change the testacase
On Wed, 10 Jul 2024 05:46:31 GMT, David Holmes wrote:
>> src/hotspot/share/utilities/exceptions.cpp line 208:
>>
>>> 206: Handle h_loader, Handle
>>> h_protection_domain) {
>>> 207: // Check for special boot-strapping/compiler-thread handling
>>> 208: if (speci
On Mon, 8 Jul 2024 19:09:47 GMT, Doug Simon wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed TestTranslatedException
>
> src/hotspot/share/utilities/exceptions.cpp line 208:
>
>> 206:
On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Narrow scope of the change.
I'd
On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Narrow scope of the change.
The
> Make well-behaved implementation expectations of Object.{toString, hashCode}
> explicit.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Narrow scope of the change.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20
> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic
> instructions. But when run with JDK 11, there is no such problem. The reason
> is the removed biased locking.
> The DecimalFormat uses StringBuffer everywhere, and St
On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi wrote:
>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and
>> will thus fall back to slower default method of `List.sort()` instead of
>> sorting a range of the array in-place in its backing root `ArrayList`.
>>
>> This
> `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`,
> thus we can remove `Iterable elements()` and `forEachElements(Consumer)`.
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
Two usages in tier3
-
On Tue, 9 Jul 2024 22:49:30 GMT, Liam Miller-Cushon wrote:
>> This change overrides mutator methods in the implementation returned by
>> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request incrementally with one
> additional commit
> This change overrides mutator methods in the implementation returned by
> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
Liam Miller-Cushon has updated the pull request incrementally with one
additional commit since the last revision:
Update test/jdk/java/util/Collection/MO
> This change overrides mutator methods in the implementation returned by
> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
Liam Miller-Cushon has updated the pull request incrementally with one
additional commit since the last revision:
Update copyright year
and add the
On Tue, 9 Jul 2024 22:43:05 GMT, Chen Liang wrote:
> All three files can have their copyright year updated.
Done
-
PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2218861123
On Tue, 9 Jul 2024 22:40:41 GMT, Liam Miller-Cushon wrote:
>> This change overrides mutator methods in the implementation returned by
>> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request incrementally with one
> additional commit
On Tue, 9 Jul 2024 22:23:57 GMT, Chen Liang wrote:
> Would you mind changing "Calling any mutator method on the Map will ..." to
> something like "... on the map or any derived view collection will ..." to
> emphasize our new consistency? (Our internal conversation agreed on this)
Done! Kevin
> This change overrides mutator methods in the implementation returned by
> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
Liam Miller-Cushon has updated the pull request incrementally with one
additional commit since the last revision:
Update unmodifiable map javadoc
--
On Fri, 26 Apr 2024 18:20:18 GMT, Liam Miller-Cushon wrote:
>> This change overrides mutator methods in the implementation returned by
>> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Please keep this open
@cushon Given we have specified in `Collection` that unmodifiabilit
`CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, thus
we can remove `Iterable elements()` and `forEachElements(Consumer)`.
-
Commit messages:
- Missed tests
- 8335905: CompoundElement API cleanup
Changes: https://git.openjdk.org/jdk/pull/20103/files
Web
On Tue, 9 Jul 2024 16:12:58 GMT, Vanitha B P wrote:
>> Created jtreg test case for
>> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.
>>
>> The JpackageTest created tests that the child process started from the app
>> launched by jpackage launcher is not automatically termina
On Mon, 8 Jul 2024 16:21:16 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> lo
> This PR attains a speed-up on some microbenchmarks by simplifying how we
> build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray
> combinator), then simplifying/inlining some of the code in the helper
> functions.
>
> Many simple concat
On Tue, 9 Jul 2024 19:41:29 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect review
>
> test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 146:
>
>> 144: @EnabledIfSystemProp
> Please review this PR which corrects a case in NumberFormat integer only
> parsing.
>
> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only
> parsing when the value has a suffix, although it caused incorrect behavior
> for the following case: when the parsed string d
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Fri, 28 Jun 2024 12:39:32 GMT, Claes Redestad wrote:
>> This PR attains a speed-up on some microbenchmarks by simplifying how we
>> build up the MH combinator tree shape
>> (only use prependers with prefix, always add a suffix to the newArray
>> combinator), then simplifying/inlining some of
On Tue, 9 Jul 2024 18:42:25 GMT, Justin Lu wrote:
> Please review this PR which corrects a case in NumberFormat integer only
> parsing.
>
> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only
> parsing when the value has a suffix, although it caused incorrect behavior
On Tue, 9 Jul 2024 19:19:41 GMT, Liam Miller-Cushon wrote:
>> There is `testImmutableCollection`/`testImmutableSet` that takes an
>> arbitrary nonexistent item for insertion/removal:
>> https://github.com/openjdk/jdk/blob/598af2e51464be089b64da4024e62865c2c6ec72/test/jdk/java/util/Collection/MO
> This change overrides mutator methods in the implementation returned by
> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
Liam Miller-Cushon has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
br
On Tue, 9 Jul 2024 17:43:32 GMT, Chen Liang wrote:
>> `testCollMutatorsAlwaysThrow` expects a `Collection` (not e.g. a
>> `Collection>`). MOAT could be refactored to handle
>> that case. Do you think that's worth it, or have thoughts about what the
>> cleanest way to do that would be?
>
> Ther
Probably best to bring this to loom-dev as there have been some
exploration into but where we decided not to expose any APIs at this time.
-Alan
On 09/07/2024 19:50, Louis Wasserman wrote:
My understanding of the structured concurrency APIs now in preview is
that when a subtask is forked, exce
> Removes ClassFile API transformation implementation details accidentally
> leaked to public API. Users don't have access to classes necessary to
> correctly implement these transform resolutions. In addition, removed
> improper `canWriteDirect` and made `ClassFileBuilder::transform` chain
> r
On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi wrote:
>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and
>> will thus fall back to slower default method of `List.sort()` instead of
>> sorting a range of the array in-place in its backing root `ArrayList`.
>>
>> This
My understanding of the structured concurrency APIs now in preview is that
when a subtask is forked, exceptions thrown in that stack trace will have
stack traces going up to the beginning of that subtask, not e.g. up the
structured concurrency task tree. (My tests suggest this is the case for
simp
Removes ClassFile API transformation implementation details accidentally leaked
to public API. Users don't have access to classes necessary to correctly
implement these transform resolutions. In addition, removed improper
`canWriteDirect` and made `ClassFileBuilder::transform` chain returns.
Re
Please review this PR which corrects a case in NumberFormat integer only
parsing.
[JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only
parsing when the value has a suffix, although it caused incorrect behavior for
the following case: when the parsed string does not cont
Le 2024-07-09 à 20 h 14, Archie Cobbs a écrit :
Gotcha - so in other words, you want a way to effectively "unwrap" the
original byte[] array so you can access the whole thing at one time
(random access), as opposed to just accessing it in online fashion as
a stream of bytes.
Indeed, I wanted
On Tue, 9 Jul 2024 02:06:34 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
Please review the fix for a major transformation bug within the ClassFile API,
where certain kinds of buffered elements produced by one transform is not sent
to the next, and the "chained" (`andThen` transformation chains) builders
returning the wrong builder for call chains.
This is intended t
On Tue, 9 Jul 2024 18:14:03 GMT, Raffaello Giulietti
wrote:
> Everything not obvious that departs from the paper by Bertot, Magaud and
> Zimmermann should be commented. Unfortunately, I can't say precisely what and
> to which extent until I see a first version.
@rgiulietti Well. Regarding the
On Tue, 2 Jul 2024 01:44:43 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
Hi Martin,
On Tue, Jul 9, 2024 at 12:31 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> I was using a custom OutputStream implementation for getting the value of
> that field, avoiding any form of copy.
>
Gotcha - so in other words, you want a way to effectively "unwrap" the
o
On Tue, 9 Jul 2024 18:04:43 GMT, Raffaello Giulietti
wrote:
> These helpful considerations, and others that are not obvious when comparing
> with the paper, should really be part of comments in the code. As mentioned,
> this helps with reviewing and for maintenance.
@rgiulietti I will add the
On Tue, 2 Jul 2024 01:44:43 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
On Tue, 9 Jul 2024 17:17:48 GMT, Raffaello Giulietti
wrote:
> Let's agree that the reference for this PR is the
> [algorithm](https://inria.hal.science/inria-00072113/document) described by
> Bertot, Magaud and Zimmermann.
>
> From a first reading, the algorithm implemented here appears diffe
On Tue, 9 Jul 2024 17:11:22 GMT, Liam Miller-Cushon wrote:
>> test/jdk/java/util/Map/MapFactories.java line 505:
>>
>>> 503:
>>> 504: @Test(expectedExceptions=UnsupportedOperationException.class)
>>> 505: public void immutableEntrySetAddAllDisallowed() {
>>
>> Looking back at MOAT, do
Hello Archie, thanks for the reply.
Le 2024-07-09 à 18 h 17, Archie Cobbs a écrit :
The difference in the old vs. new behavior is the use of a 128k
temporary transfer buffer. So if I understand this correctly the
performance problem you are addressing (in terms of blown cache) is
not proporti
On Tue, 2 Jul 2024 01:44:43 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
On Mon, 8 Jul 2024 20:39:38 GMT, Chen Liang wrote:
>> Liam Miller-Cushon 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 six
>> additional commi
On Tue, Jul 9, 2024 at 10:51 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> JDK-22 has modified ByteArrayInputStream.transferTo(OutputStream)
> implementation for performing a defensive copy of the byte array when the
> destination is not trusted (JDK-8321053). However, I was
> Created jtreg test case for
> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.
>
> The JpackageTest created tests that the child process started from the app
> launched by jpackage launcher is not automatically terminated when the the
> launcher is terminated.
Vanitha B P ha
Please review this trivial test-only change to resolve a name clash with a
jtreg-reserved property by removing the third option to control a test
verbosity level via the `test.verbose` system property.
The fix assumes that the system property was only used in a manual scenario,
like `make test
Hello
JDK-22 has modified ByteArrayInputStream.transferTo(OutputStream)
implementation for performing a defensive copy of the byte array when
the destination is not trusted (JDK-8321053). However, I was using the
previous implementation as a trick for reading the array without copy.
The reaso
On Tue, 9 Jul 2024 14:26:11 GMT, Alexey Semenyuk wrote:
>> Vanitha B P has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressed the review comments based on the inputs
>
> test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java line 3
On Tue, 9 Jul 2024 14:42:42 GMT, Doug Simon wrote:
>> test/jdk/jdk/internal/vm/TestTranslatedException.java line 167:
>>
>>> 165: private static void assertThrowableEquals(Throwable originalIn,
>>> Throwable decodedIn) {
>>> 166: Throwable original = originalIn;
>>> 167: Thr
On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote:
>> This PR addresses intermittent failures in jtreg GC stress tests. The
>> failures occur under these conditions:
>> 1. Using a libgraal build with assertions enabled as the top tier JIT
>> compiler. Such a libgraal build will cause a VM exit
On Tue, 9 Jul 2024 14:37:47 GMT, Yudi Zheng wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed TestTranslatedException
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 782:
>
>> 780: while (true) {
>>
On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote:
>> This PR addresses intermittent failures in jtreg GC stress tests. The
>> failures occur under these conditions:
>> 1. Using a libgraal build with assertions enabled as the top tier JIT
>> compiler. Such a libgraal build will cause a VM exit
On Tue, 9 Jul 2024 10:49:06 GMT, Vanitha B P wrote:
>> Created jtreg test case for
>> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.
>>
>> The JpackageTest created tests that the child process started from the app
>> launched by jpackage launcher is not automatically termina
> This PR addresses intermittent failures in jtreg GC stress tests. The
> failures occur under these conditions:
> 1. Using a libgraal build with assertions enabled as the top tier JIT
> compiler. Such a libgraal build will cause a VM exit if an assertion or
> GraalError occurs in a compiler thr
On Mon, 8 Jul 2024 14:14:02 GMT, Adam Sotona wrote:
>> Class-File API constant pool implementation requires non-zero entry hash
>> code.
>> Unfortunately current implementation computes zero hash code for specific CP
>> entries.
>>
>> This patch removes invalid and obsolete `AbstractPoolEntry:
This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
order to help improve vectorization performance.
Currently vectorization does not kick in for loops containing either of these
calls because of the following error:
VLoop::check_preconditions: failed: control flow in
> Created jtreg test case for
> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.
>
> The JpackageTest created tests that the child process started from the app
> launched by jpackage launcher is not automatically terminated when the the
> launcher is terminated.
Vanitha B P ha
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
> propos
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
> propos
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
> propos
On Mon, 8 Jul 2024 19:01:05 GMT, Doug Simon wrote:
> This PR addresses intermittent failures in jtreg GC stress tests. The
> failures occur under these conditions:
> 1. Using a libgraal build with assertions enabled as the top tier JIT
> compiler. Such a libgraal build will cause a VM exit if a
This PR addresses intermittent failures in jtreg GC stress tests. The failures
occur under these conditions:
1. Using a libgraal build with assertions enabled as the top tier JIT compiler.
Such a libgraal build will cause a VM exit if an assertion or GraalError occurs
in a compiler thread (as th
70 matches
Mail list logo
