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 Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman wrote:
> Virtual threads created directly with the Thread API are not included in the
> new thread dump by default. This was a source of confusion in JDK 19/20 when
> virtual threads were in preview. We have decided to switch the default so
> that
On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman wrote:
> Virtual threads created directly with the Thread API are not included in the
> new thread dump by default. This was a source of confusion in JDK 19/20 when
> virtual threads were in preview. We have decided to switch the default so
> that
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(
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(
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 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
> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a
> well-known pain. JDK-8252842 have added parallel support to heapdump in an
> attempt to alleviate this issue. However, all concurrent threads
> competitively write heap data to the sam
> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a
> well-known pain. JDK-8252842 have added parallel support to heapdump in an
> attempt to alleviate this issue. However, all concurrent threads
> competitively write heap data to the sam
On Mon, 5 Jun 2023 23:44:04 GMT, Alex Menkov wrote:
> A lot of code movement is caused by moving AbstractDumpWriter class from
> heapDumper.cpp to heapDumpCompression.hpp/cpp
> I'm not happy with huge heapDumper.cpp file, but this refactoring does not
> look good to me.
> Currently all logic ab
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 `VM_Ge
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(String targetName) {
List argList = new ArrayList<>(Arrays.a
On Fri, 2 Jun 2023 21:41:32 GMT, Chris Plummer wrote:
> The com/sun/jdi/JdbXXX tests rely on the jdb "threads" command output to find
> the main thread. If it is a virtual thread, it will not be included in the
> "threads" output unless the debuggee is run with -Djdk.trackAllThreads, so we
> n
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 19:13:30 GMT, Serguei Spitsyn wrote:
>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
>> allow deployment to choose whether to allow agents to be loaded/started in
>> the VM. The VM option does the right thing for tools using the Attach API
>>
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
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
with includevirtualthreads=y. As a result the thread is not found
On Wed, 31 May 2023 10:08:46 GMT, Serguei Spitsyn wrote:
> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
> allow deployment to choose whether to allow agents to be loaded/started in
> the VM. The VM option does the right thing for tools using the Attach API but
>
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, 17 May 2023 09:23:17 GMT, Yi Yang wrote:
>> ### Motivation and proposal
>> Hi, heap dump brings about pauses for application's execution(STW), this is
>> a well-known pain. JDK-8252842 have added parallel support to heapdump in an
>> attempt to alleviate this issue. However, all concurr
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
immediately exits after creating the test threads, and at that poin
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 the
vi
On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman wrote:
> Virtual threads created directly with the Thread API are not included in the
> new thread dump by default. This was a source of confusion in JDK 19/20 when
> virtual threads were in preview. We have decided to switch the default so
> that
On Sun, 4 Jun 2023 11:14:06 GMT, Alan Bateman wrote:
>> The lines 763-764 are to correct the state exactly for passive carrier
>> thread, a carrier thread which can't progress until the execution control
>> has not been returned from a virtual thread executed on the top. It is never
>> for a p
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 Mon, 5 Jun 2023 19:13:30 GMT, Serguei Spitsyn wrote:
>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
>> allow deployment to choose whether to allow agents to be loaded/started in
>> the VM. The VM option does the right thing for tools using the Attach API
>>
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 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 15:10:18 GMT, Alan Bateman wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java
>> line 660:
>>
>>> 658: expectedMethods.add(Thread.class.getName() + ".sleep");
>>> 659: expectedMethods.add(Thread.class.getName() + ".sleepNanos");
On Mon, 5 Jun 2023 19:13:30 GMT, Serguei Spitsyn wrote:
>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
>> allow deployment to choose whether to allow agents to be loaded/started in
>> the VM. The VM option does the right thing for tools using the Attach API
>>
On Mon, 5 Jun 2023 17:25:43 GMT, Aleksey Shipilev wrote:
> I think we need to delay this until
> [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in
> case we would like to revert
> [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092).
Okay, I won't integrate this
> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
> allow deployment to choose whether to allow agents to be loaded/started in
> the VM. The VM option does the right thing for tools using the Attach API but
> jcmd JVMTI.agent_load was missed. This should be fixed to
> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
> allow deployment to choose whether to allow agents to be loaded/started in
> the VM. The VM option does the right thing for tools using the Attach API but
> jcmd JVMTI.agent_load was missed. This should be fixed to
> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
> allow deployment to choose whether to allow agents to be loaded/started in
> the VM. The VM option does the right thing for tools using the Attach API but
> jcmd JVMTI.agent_load was missed. This should be fixed to
> 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 19:27:28 GMT, Alex Menkov wrote:
>> test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 42:
>>
>>> 40: * @library /test/lib
>>> 41: *
>>> 42: * @run main/othervm -XX:-EnableDynamicAgentLoading TestJcmdNoAgentLoad
>>
>> The test verifies only one scenario. I think we need
On Sun, 4 Jun 2023 11:36:05 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add to TestJcmdNoAgentLoad default and enabled dynamic loading
>> modes
>
> test/jdk/sun/tools/jcmd/TestJcmd
> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
> allow deployment to choose whether to allow agents to be loaded/started in
> the VM. The VM option does the right thing for tools using the Attach API but
> jcmd JVMTI.agent_load was missed. This should be fixed to
On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman wrote:
> Virtual threads created directly with the Thread API are not included in the
> new thread dump by default. This was a source of confusion in JDK 19/20 when
> virtual threads were in preview. We have decided to switch the default so
> that
On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman wrote:
> Virtual threads created directly with the Thread API are not included in the
> new thread dump by default. This was a source of confusion in JDK 19/20 when
> virtual threads were in preview. We have decided to switch the default so
> that
On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman wrote:
> Thread.sleep has had quite a bit of churn recently to support virtual
> threads, add sleep(Duration), a JFR event, and the change the underlying
> implementation to support sub-millis precision. I think the changes have
> settled down now
On Fri, 2 Jun 2023 02:49:25 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
Virtual threads created directly with the Thread API are not included in the
new thread dump by default. This was a source of confusion in JDK 19/20 when
virtual threads were in preview. We have decided to switch the default so that
all virtual threads are observable. Future work will reduce/rem
On Mon, 5 Jun 2023 07:26:57 GMT, David Holmes wrote:
>> Thread.sleep has had quite a bit of churn recently to support virtual
>> threads, add sleep(Duration), a JFR event, and the change the underlying
>> implementation to support sub-millis precision. I think the changes have
>> settled down
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 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 Mon, 5 Jun 2023 12:46:58 GMT, Kelvin Nilsen wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove three asserts making comparisons between atomic volatile variables
>>
>> Though changes to the volatile va
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 11:28:33 GMT, Alan Bateman wrote:
> Thread.sleep has had quite a bit of churn recently to support virtual
> threads, add sleep(Duration), a JFR event, and the change the underlying
> implementation to support sub-millis precision. I think the changes have
> settled down now
On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman wrote:
> Thread.sleep has had quite a bit of churn recently to support virtual
> threads, add sleep(Duration), a JFR event, and the change the underlying
> implementation to support sub-millis precision. I think the changes have
> settled down now
51 matches
Mail list logo
