On Wed, 7 Jun 2023 01:05:07 GMT, Alex Menkov wrote:
> I guess, your suggestion is `is_carrying_virtual_thread`. Is it right? If so,
> I like this suggestion.
Good, I think will be easy to understand at the use sites.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14298#disc
On Tue, 6 Jun 2023 22:41:54 GMT, Serguei Spitsyn wrote:
>> When a virtual thread is mounted, the carrier thread should be reported as
>> "waiting" until the virtual thread unmounts. Right now, GetThreadState
>> reports a state based the JavaThread status when it should return
>> JVMTI_THREAD_S
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Tue, 6 Jun 2023 23:42:24 GMT, Serguei Spitsyn wrote:
> > is_carrying_carrier_thread? a bit artificial, but it's a carrier thread and
> > it's carrying a virtual thread
>
> I guess, your suggestion is `is_carrying_virtual_thread`. Is it right? If so,
> I like this suggestion.
Up to you. I t
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a
> c
On Tue, 6 Jun 2023 23:39:54 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: call get_thread_state_base only when needed
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 386:
>
>> 384:
On Tue, 6 Jun 2023 23:20:53 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: ThreadListStackTracesTest cleanup
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTes
> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
> VirtualThread blocked on a monitor when called for more than one thread. When
> called for a single VirtualThread it correctly returns a state that includes
> the `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` flag.
>
On Tue, 6 Jun 2023 23:37:03 GMT, Alex Menkov wrote:
> is_carrying_carrier_thread? a bit artificial, but it's a carrier thread and
> it's carrying a virtual thread
I guess, your suggestion is `is_carrying_virtual_thread`. Is it right?
If so, I like this suggestion.
-
PR Review Comm
On Tue, 6 Jun 2023 22:41:54 GMT, Serguei Spitsyn wrote:
>> When a virtual thread is mounted, the carrier thread should be reported as
>> "waiting" until the virtual thread unmounts. Right now, GetThreadState
>> reports a state based the JavaThread status when it should return
>> JVMTI_THREAD_S
On Sat, 3 Jun 2023 15:17:37 GMT, Y. Srinivas Ramakrishna
wrote:
>> Yes. And also from files which were changed by non-Amazon employees only,
>> please.
>
> Thanks, Martin. Yes, we have noted that there were a few other files that
> were inadvertently caught in a copyright header dragnet. These
On Tue, 6 Jun 2023 22:06:14 GMT, Serguei Spitsyn wrote:
>>> Okay, I see you point. Unfortunately, I've always referred the platform
>>> thread with an executed FJP schedular as a carrier thread. The term
>>> 'carrier' with this meaning is everywhere in the JVMTI code. It looks very
>>> confusi
On Fri, 2 Jun 2023 17:55:56 GMT, Y. Srinivas Ramakrishna
wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Force PLAB sizes to align on card-table size
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 12
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a
> c
On Tue, 6 Jun 2023 22:54:04 GMT, Serguei Spitsyn wrote:
>> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
>> VirtualThread blocked on a monitor when called for more than one thread.
>> When called for a single VirtualThread it correctly returns a state that
>> inclu
On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer wrote:
> The test has two issues. The first is that it assume that once the VMStart
> event has arrived and one "step into" is done, it will be in the main method
> of the debuggee. Once there, it determines the debuggee class name by looking
> at
On Tue, 6 Jun 2023 00:02:47 GMT, Chris Plummer wrote:
> The test fails with the virtual test thread factory because it tries to find
> the "main" thread in the list of threads returned by JDI, but "main" is a
> virtual thread and will only be returned by JDI if the debug agent is
> launched wi
On Tue, 6 Jun 2023 22:34:33 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressed new test related review comments
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTe
On Tue, 6 Jun 2023 21:37:25 GMT, Serguei Spitsyn wrote:
>> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
>> VirtualThread blocked on a monitor when called for more than one thread.
>> When called for a single VirtualThread it correctly returns a state that
>> inclu
> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
> VirtualThread blocked on a monitor when called for more than one thread. When
> called for a single VirtualThread it correctly returns a state that includes
> the `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` flag.
>
On Tue, 6 Jun 2023 22:17:57 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: removed JVMTI_THREAD_STATE_RUNNABLE from a carrier thread state
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp l
On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer wrote:
> com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java currently overrides
> the TestScaffold.startup() method:
>
> // override this to correct a bug so arguments can be passed to
> // the Target class
> protected void startUp(
> When a virtual thread is mounted, the carrier thread should be reported as
> "waiting" until the virtual thread unmounts. Right now, GetThreadState
> reports a state based the JavaThread status when it should return
> JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY.
> The
On Tue, 6 Jun 2023 21:37:25 GMT, Serguei Spitsyn wrote:
>> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
>> VirtualThread blocked on a monitor when called for more than one thread.
>> When called for a single VirtualThread it correctly returns a state that
>> inclu
On Tue, 6 Jun 2023 22:07:14 GMT, Serguei Spitsyn wrote:
>> When a virtual thread is mounted, the carrier thread should be reported as
>> "waiting" until the virtual thread unmounts. Right now, GetThreadState
>> reports a state based the JavaThread status when it should return
>> JVMTI_THREAD_S
On Tue, 6 Jun 2023 15:43:02 GMT, Alan Bateman wrote:
>> Okay, I see you point. Unfortunately, I've always referred the platform
>> thread with an executed FJP schedular as a carrier thread. The term
>> 'carrier' with this meaning is everywhere in the JVMTI code. It looks very
>> confusing to c
On Tue, 6 Jun 2023 21:22:40 GMT, Alex Menkov wrote:
>> Serguei Spitsyn 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 three additional
>> commi
> When a virtual thread is mounted, the carrier thread should be reported as
> "waiting" until the virtual thread unmounts. Right now, GetThreadState
> reports a state based the JavaThread status when it should return
> JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY.
> The
On Fri, 2 Jun 2023 21:47:47 GMT, Chris Plummer wrote:
> JdbMethodExitTest.java tries to determine the jdb threadID for the "main"
> thread, and then later use it in jdb commands that require a threadID. It
> does this by first having the debuggee execute the following:
>
> `System.out.
On Tue, 6 Jun 2023 20:07:33 GMT, Chris Plummer wrote:
>> JdbMethodExitTest.java tries to determine the jdb threadID for the "main"
>> thread, and then later use it in jdb commands that require a threadID. It
>> does this by first having the debuggee execute the following:
>>
>> `System
On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 wrote:
> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
> code https://github.com/openjdk/jdk/pull/14146
> It handles the part in security and servicability.
>
> Compiling on AIX with xlc17 which contains the new clang 15 fr
On Thu, 1 Jun 2023 14:25:19 GMT, Thomas Stuefe wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exit during initialization on unsupported platforms
>
> test/hotspot/jtreg/gc/shenandoah/oom/TestAllocOutOfMemory.java
On Tue, 6 Jun 2023 21:43:36 GMT, Kelvin Nilsen wrote:
>> test/hotspot/jtreg/gc/shenandoah/TestEvilSyncBug.java line 33:
>>
>>> 31: * @modules java.base/jdk.internal.misc
>>> 32: * java.management
>>> 33: * @run driver/timeout=480 TestEvilSyncBug
>>> -XX:ShenandoahGCHeuristics=aggres
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that the
On Tue, 6 Jun 2023 20:43:36 GMT, Martin Doerr wrote:
>> The sys_thread_3() function contains an empty while loop, which by the
>> standard can be optimized away. Please refer to discussion in
>> https://github.com/llvm/llvm-project/issues/60622
>> The xlc17 compiler is doing so, and IBM claims
On Tue, 6 Jun 2023 21:37:25 GMT, Serguei Spitsyn wrote:
>> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
>> VirtualThread blocked on a monitor when called for more than one thread.
>> When called for a single VirtualThread it correctly returns a state that
>> inclu
On Thu, 1 Jun 2023 13:32:49 GMT, Thomas Stuefe wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exit during initialization on unsupported platforms
>
> test/hotspot/jtreg/gc/shenandoah/TestEvilSyncBug.java line 33:
> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
> VirtualThread blocked on a monitor when called for more than one thread. When
> called for a single VirtualThread it correctly returns a state that includes
> the `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` flag.
>
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a
> c
On Tue, 6 Jun 2023 21:07:46 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - fixed typo in a comment in jvmtiEnvBase.cpp
>> - nit: restored one comment as was before
>
> test/hotspot/jtreg/s
On Mon, 5 Jun 2023 19:00:49 GMT, Serguei Spitsyn wrote:
>> When a virtual thread is mounted, the carrier thread should be reported as
>> "waiting" until the virtual thread unmounts. Right now, GetThreadState
>> reports a state based the JavaThread status when it should return
>> JVMTI_THREAD_S
On Tue, 6 Jun 2023 13:37:03 GMT, Serguei Spitsyn wrote:
>> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
>> VirtualThread blocked on a monitor when called for more than one thread.
>> When called for a single VirtualThread it correctly returns a state that
>> inclu
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a
> c
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that the
On Tue, 6 Jun 2023 20:01:02 GMT, Christine Flood wrote:
> We'd like to propose to push now, and tackle/fix the single-gen issue you
> identified during RDP1, as well as any other significant single-gen
> regressions that may come up. We have four Shen experts on board, Roman,
> Aleksey, Kelvin
> JdbMethodExitTest.java tries to determine the jdb threadID for the "main"
> thread, and then later use it in jdb commands that require a threadID. It
> does this by first having the debuggee execute the following:
>
> `System.out.println("threadid="+Thread.currentThread().getId());`
>
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Tue, 6 Jun 2023 19:48:05 GMT, Paul Hohensee wrote:
> We'd like to propose to push now, and tackle/fix the single-gen issue you
> identified during RDP1, as well as any other significant single-gen
> regressions that may come up. We have four Shen experts on board, Roman,
> Aleksey, Kelvin,
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer wrote:
> The test has two issues. The first is that it assume that once the VMStart
> event has arrived and one "step into" is done, it will be in the main method
> of the debuggee. Once there, it determines the debuggee class name by looking
> at
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Sun, 4 Jun 2023 18:47:13 GMT, Chris Plummer wrote:
>> JdbMethodExitTest.java tries to determine the jdb threadID for the "main"
>> thread, and then later use it in jdb commands that require a threadID. It
>> does this by first having the debuggee execute the following:
>>
>> `System
> The test fails because it tries to determine the main debuggee thread by
> allowing it run until the debuggee class is loaded (it waits for the
> ClassPrepareEvent). Normally this would be done on the main debuggee thread.
> However, when using virtual threads, the main thread has yet to spawn
On Mon, 5 Jun 2023 21:55:02 GMT, Chris Plummer wrote:
> The test fails because it tries to determine the main debuggee thread by
> allowing it run until the debuggee class is loaded (it waits for the
> ClassPrepareEvent). Normally this would be done on the main debuggee thread.
> However, when
On Mon, 5 Jun 2023 21:55:02 GMT, Chris Plummer wrote:
> The test fails because it tries to determine the main debuggee thread by
> allowing it run until the debuggee class is loaded (it waits for the
> ClassPrepareEvent). Normally this would be done on the main debuggee thread.
> However, when
On Mon, 5 Jun 2023 22:13:29 GMT, Chris Plummer wrote:
> The test fails when the main debuggee thread is a virtual thread, because
> virtual threads are always daemon threads. Because of this all the test
> threads that the debuggee creates are also daemon threads. The main deuggee
> thread imm
On Mon, 5 Jun 2023 22:13:29 GMT, Chris Plummer wrote:
> The test fails when the main debuggee thread is a virtual thread, because
> virtual threads are always daemon threads. Because of this all the test
> threads that the debuggee creates are also daemon threads. The main deuggee
> thread imm
On Tue, 6 Jun 2023 17:32:35 GMT, Artem Semenov wrote:
>> I didn't ask to revert the change. It's
>> `s/TARGET_OS_MAC/defined(__APPLE__)/`.
>
> This is rarely used in the code and is not the essence of the current changes.
> If you introduce such changes, then throughout the code.
> Moreover, thi
On Thu, 1 Jun 2023 15:04:09 GMT, Weijun Wang wrote:
>> done
>
> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.
This is rarely used in the code and is not the essence of the current changes.
If you introduce such changes, then throughout the code.
Moreover, this ca
On Mon, 5 Jun 2023 21:26:39 GMT, Serguei Spitsyn wrote:
> Okay, I see you point. Unfortunately, I've always referred the platform
> thread with an executed FJP schedular as a carrier thread. The term 'carrier'
> with this meaning is everywhere in the JVMTI code. It looks very confusing to
> ca
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters wrote:
>> C11 has been stable for a long time on all platforms, so native code can use
>> the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional
> commits since th
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
> VirtualThread blocked on a monitor when called for more than one thread. When
> called for a single VirtualThread it correctly returns a state that includes
> the `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` flag.
>
> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
> VirtualThread blocked on a monitor when called for more than one thread. When
> called for a single VirtualThread it correctly returns a state that includes
> the `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` flag.
>
On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 wrote:
> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
> code https://github.com/openjdk/jdk/pull/14146
> It handles the part in security and servicability.
>
> Compiling on AIX with xlc17 which contains the new clang 15 fr
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that the
On Tue, 9 May 2023 04:17:28 GMT, Chen Liang wrote:
>> Summaries:
>> 1. A few recommendations about updating the constant API is made at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html
>> and I may update this patch shall the API changes be integrated before
>> 2.
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that the
On Mon, 5 Jun 2023 20:05:24 GMT, Chris Plummer wrote:
> The following commit in loom heavily modified this file with a lot of added
> expected methods. There are other related tests with similar changes. I'm not
> so sure I understand the need for so many additions, and also why
> expectedLeng
The sys_thread_3() function contains an empty while loop, which by the standard
can be optimized away. Please refer to discussion in
https://github.com/llvm/llvm-project/issues/60622
The xlc17 compiler is doing so, and IBM claims that they are following the
standard and will not fix this on comp
On Tue, 6 Jun 2023 07:30:26 GMT, David Holmes wrote:
> Just a passing comment but I happened to notice today that when a virtual
> thread blocks on a legacy synchronization mechanism, it delegates to its
> carrier thread to report its state. It is not at all clear to me how this is
> handled a
On Tue, 6 Jun 2023 00:50:34 GMT, Serguei Spitsyn wrote:
> The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a
> VirtualThread blocked on a monitor when called for more than one thread. When
> called for a single VirtualThread it correctly returns a state that includes
>
76 matches
Mail list logo
