On Wed, 14 Aug 2024 21:02:47 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use jdk.test.lib.Utils.getRandomInstance()
>
> src/hotspot/share/runtime/synchronizer.hpp line 126:
>
> 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 looser
> semantics to use this displaced data. In Lilliput this data als
On Wed, 14 Aug 2024 20:58:24 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:
>>
>>> 339:
>>> 340: ObjectMonitor*
>>> LightweightSynchronizer::get_or_insert_monitor_from_table(oop object,
>>> JavaThread* current, bool* inserted) {
>>> 341:
On Wed, 14 Aug 2024 20:53:33 GMT, Markus Grönlund wrote:
> Greetings,
>
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor
> because migrating a carrier thread local event writer object onto another
> carrier thread is impossible.
>
> During event commit, the threa
On Wed, 14 Aug 2024 22:11:39 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1075:
>>
>>> 1073: /**
>>> 1074: * Tries to join this task, returning true if it completed
>>> 1075: * (possibly exceptionally) before the given timeout e
On Mon, 12 Aug 2024 06:29:03 GMT, Jatin Bhateja wrote:
> its usage in existing patch is limited to [type
> comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542)
Ah, that makes sense to me. I took a closer look an
On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen wrote:
> j.u.Formatter$FixedString can be refactored to simplify the code using Record
A simple cleanup.
-
Marked as reviewed by liach (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20443#pullrequestreview-2239320206
On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen wrote:
> j.u.Formatter$FixedString can be refactored to simplify the code using Record
Marked as reviewed by redestad (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20443#pullrequestreview-2239308638
On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen wrote:
> j.u.Formatter$FixedString can be refactored to simplify the code using Record
src/java.base/share/classes/java/util/Formatter.java line 3024:
> 3022: }
> 3023:
> 3024: private static record FixedString(String s, int start, int end)
j.u.Formatter$FixedString can be refactored to simplify the code using Record
-
Commit messages:
- Update src/java.base/share/classes/java/util/Formatter.java
- use record to simplify code
Changes: https://git.openjdk.org/jdk/pull/20443/files
Webrev: https://webrevs.openjdk.org/?
On Wed, 14 Aug 2024 21:03:05 GMT, Kevin Bourrillion wrote:
>> This PR fixes a few trivial grammar issues and typos in documentation.
>>
>> The main issue is the use of the word "timeout". To my mind, timeout, a
>> duration, is not the same as deadline, which is a point in time, an instant,
>>
On Tue, 13 Aug 2024 17:24:19 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> sr
On Wed, 14 Aug 2024 09:24:34 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
>> l
On Wed, 14 Aug 2024 13:38:34 GMT, Pavel Rappo wrote:
> This PR fixes a few trivial grammar issues and typos in documentation.
>
> The main issue is the use of the word "timeout". To my mind, timeout, a
> duration, is not the same as deadline, which is a point in time, an instant,
> which allow
Greetings,
Explicitly pin a virtual thread before acquiring the JFR string pool monitor
because migrating a carrier thread local event writer object onto another
carrier thread is impossible.
During event commit, the thread is in a critical section because it has loaded
a carrier thread local
`BytecodeHelpers.handleConstantDescToHandleInfo` is incorrectly using
`DirectMethodHandleDesc.invocationType`, which accidentally works for static
bootstrap methods so it's discovered only now with more extensive testing from
bytebuddy. Cleaned up by reusing the correct `handleDescToHandleInfo`
On Wed, 14 Aug 2024 03:26:02 GMT, Jan Kratochvil
wrote:
>> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 217:
>>
>>> 215:
>>> 216: // KFAIL - verify the
>>> CgroupSubsystem::initialize_hierarchy() and
>>> jdk.internal.platform.CgroupSubsystem.initializeHierarchy() b
On Wed, 14 Aug 2024 02:59:33 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>>
>> Fix by Severin Gehwolf.
>> Testcase by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Testcase u
On Fri, 26 Jul 2024 06:29:05 GMT, SendaoYan wrote:
>> Hi all,
>> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails
>> on rpm build mock environment. The `df -h` command return fail `df: cannot
>> read table of mounted file systems: No such file or directory` on the rpm
On Wed, 14 Aug 2024 13:52:11 GMT, Alan Bateman wrote:
> The testing scenario is very unusual but I think it's okay to skip when POSIX
> permissions aren't supported.
Thanks. /integrate
-
PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2289149517
On Wed, 14 Aug 2024 09:35:10 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/vframe.cpp line 252:
>>
>>> 250: if (mark.has_monitor()) {
>>> 251: ObjectMonitor* mon =
>>> ObjectSynchronizer::read_monitor(current, monitor->owner(), mark);
>>> 252:
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size z
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Thu, 25 Jul 2024 13:23:37 GMT, Alan Bateman wrote:
>>> Okay, but doesn't mean that lots of other tests will fail too, esp. tests
>>> in jdk_nio test group.
>>
>> Currently we observer only this test fails of tier1.
>
>> > Okay, but doesn't mean that lots of other tests will fail too, esp. te
This PR fixes a few trivial grammar issues and typos in documentation.
The main issue is the use of the word "timeout". To my mind, timeout, a
duration, is not the same as deadline, which is a point in time, an instant,
which allows "before" and "after". While one can think of timeout as of an
On Wed, 19 Jun 2024 12:52:46 GMT, Alan Bateman wrote:
>> @AlanBateman -- could you please take a look? Thanks.
>
>> @AlanBateman -- could you please take a look? Thanks.
>
> There was a lot of heap analysis done a few years ago that shined a light on
> the number of empty collections in a typic
On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Thu, 25 Jul 2024 13:23:37 GMT, Alan Bateman wrote:
>>> Okay, but doesn't mean that lots of other tests will fail too, esp. tests
>>> in jdk_nio test group.
>>
>> Currently we observer only this test fails of tier1.
>
>> > Okay, but doesn't mean that lots of other tests will fail too, esp. te
> Can I please get a review for this patch which proposes to implement the
> enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>
> The commit in this PR introduces the `-o` and `--output-dir` option to the
> `jar` command. The option takes a path to a destination dir
On 13/08/2024 17:48, Liam Miller-Cushon wrote:
Hi,
I have a data point to share on the compatibility impact of
JDK-8325621 (Improve jspawnhelper version checks), which was
backported to earlier release trains.
As a result of that change, doing an in-place upgrade from 22.0.1 to
22.0.2 breaks lo
On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Wed, 14 Aug 2024 09:45:24 GMT, Shaojin Wen wrote:
> In the `StringConcat.concat123String` scenario, setting the inlineThreshold
> to 150 still shows a performance improvement, although this is crazy. But
> this can be used as a performance optimization parameter.
I'd suggest looking at JIT
On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Tue, 13 Aug 2024 21:56:29 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/share/runtime/vframe.cpp line 252:
>
>> 250: if (mark.ha
On Wed, 14 Aug 2024 09:11:21 GMT, Shaojin Wen wrote:
> Is there any work for me to do?
No, barring any further review comments from others I think we're good for this
PR.
Reaching out and getting help evaluating this at scale would be very valuable.
So far I've only seen positives when testi
> 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 looser
> semantics to use this displaced data. In Lilliput this data als
On Tue, 13 Aug 2024 19:56:22 GMT, Chen Liang wrote:
>> `TypeAnnotation` is not an annotation, as it should not be used in places
>> like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an
>> annotation at a given location instead of to be an annotation.
>>
>> Depends on #20205.
On Wed, 14 Aug 2024 07:47:20 GMT, Claes Redestad wrote:
> Tier 1-5 testing passed (a few unrelated test failures)
Is there any work for me to do?
-
PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288249819
On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Tue, 13 Aug 2024 14:37:32 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014)
>> improving the use of `@jvms` tags by adding `JVMS` prior to the tag.
>>
>> Thanks,
>> Sonia
>
> Sonia Zaldana Calles has updated the pu
On Tue, 13 Aug 2024 16:03:16 GMT, Roman Kennke wrote:
>> I tried the following (see diff below) and it shows about a 5-10% regression
>> in most the `LockUnlock.testInflated*` micros. Also tried with just
>> `num_unrolled = 1` saw the same regression. Maybe there was some other
>> pattern you
On Wed, 14 Aug 2024 05:45:27 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 84:
>
>> 82:
>> 83: if (
> 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 looser
> semantics to use this displaced data. In Lilliput this data als
On Wed, 14 Aug 2024 07:33:19 GMT, David Holmes wrote:
> When we have `Catch (Error | RuntimeException ex)` exactly what
> RuntimeExceptions are we trying to account for - because they should not
> happen and may break the synchronizer if they do.
Right now, the catch is just defending against
On Tue, 13 Aug 2024 21:45:57 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/share/runtime/synchronizer.cpp line 1271:
>
>> 1269: _no_pro
On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Mon, 12 Aug 2024 22:03:44 GMT, Paul Sandoz wrote:
> The results look promising. I can provide guidance on the specification e.g.,
> we can specify the behavior in terms of rearrange, with the addition of
> throwing on out of bounds indexes.
>
> Regarding the throwing of exceptions, some wid
On Mon, 12 Aug 2024 16:11:46 GMT, Viktor Klang wrote:
>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when
>> failing due to a LinkageError or other errors
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Tue, 13 Aug 2024 21:05:29 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> sr
On Tue, 13 Aug 2024 22:03:54 GMT, David Holmes wrote:
> AFAICS `await` would call the acquire method that was changed here. I know we
> have issues with OOME and SOE, but these changes admit more general exception
> possibilities that would seem to undermine the required guarantee. But
> perha
On Tue, 13 Aug 2024 18:13:30 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> sr
55 matches
Mail list logo
