On Mon, 2 Oct 2023 23:11:01 GMT, Serguei Spitsyn wrote:
> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
> pattern and so, should not be thread-filtered.
> The fix includes:
> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
> `VirtuallThreadStart` event
On Tue, 10 Oct 2023 02:44:53 GMT, Chris Plummer wrote:
>> A JavaThread can be hidden, not a virtual thread.
>> For such a case, I'd treat it that a carrier thread is hidden.
>> The assert is to catch if it ever happens.
>> Do you think this assert is an overkill?
>
> Never mind. I see you changed
On Tue, 10 Oct 2023 00:54:42 GMT, Serguei Spitsyn wrote:
>> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
>> pattern and so, should not be thread-filtered.
>> The fix includes:
>> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
>> `VirtuallThreadStart`
On Fri, 6 Oct 2023 19:24:03 GMT, Leonid Mesnik wrote:
> I marked tests
> sun/tools/jcmd/TestProcessHelper.java
> sun/tools/jinfo/JInfoTest.java
> as headless. They used different specific VM options and are not worth
> executing with other VM flags.
> And fixed
> sun/tools/jstat/JStatInterval
On Tue, 10 Oct 2023 00:39:10 GMT, Serguei Spitsyn wrote:
>> I still would like to know how we might end up with a hidden virtual thread.
>
> A JavaThread can be hidden, not a virtual thread.
> For such a case, I'd treat it that a carrier thread is hidden.
> The assert is to catch if it ever happe
On Tue, 10 Oct 2023 00:54:42 GMT, Serguei Spitsyn wrote:
>> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
>> pattern and so, should not be thread-filtered.
>> The fix includes:
>> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
>> `VirtuallThreadStart`
On Fri, 6 Oct 2023 20:47:22 GMT, Leonid Mesnik wrote:
> Test fixed to accept vm flags.
Looks good modulo comment from Kevin.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16081#pullrequestreview-1665736592
On Tue, 10 Oct 2023 00:54:42 GMT, Serguei Spitsyn wrote:
>> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
>> pattern and so, should not be thread-filtered.
>> The fix includes:
>> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
>> `VirtuallThreadStart`
On Fri, 6 Oct 2023 19:58:13 GMT, Leonid Mesnik wrote:
> The test uses specific classpath, and jar and is intended to test modules. So
> I marked is as flagless,
Looks good.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16
> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
> pattern and so, should not be thread-filtered.
> The fix includes:
> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
> `VirtuallThreadStart` event spec
> - `jvmtiEventController.cpp`: remove the `VTHREAD
On Tue, 10 Oct 2023 00:21:27 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: removed unneeded comment
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1614:
>
>> 1612:
>> 1613: // Do
On Tue, 10 Oct 2023 00:09:53 GMT, Chris Plummer wrote:
>> Good catch, thanks. Forgot to remove this comment. Fixed now.
>
> I still would like to know how we might end up with a hidden virtual thread.
A JavaThread can be hidden, not a virtual thread.
For such a case, I'd treat it that a carrier
On Tue, 10 Oct 2023 00:02:48 GMT, Serguei Spitsyn wrote:
>> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
>> pattern and so, should not be thread-filtered.
>> The fix includes:
>> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
>> `VirtuallThreadStart`
On Mon, 9 Oct 2023 23:52:40 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 1581:
>>
>>> 1579: assert(!thread->is_hidden_from_external_view(), "carrier threads
>>> can't be hidden");
>>> 1580:
>>> 1581: // Do not post virtual thread start event for hidden java t
> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
> pattern and so, should not be thread-filtered.
> The fix includes:
> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
> `VirtuallThreadStart` event spec
> - `jvmtiEventController.cpp`: remove the `VTHREAD
On Fri, 6 Oct 2023 22:59:56 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: convert check for is_hidden_from_external_view check() into assert
>
> src/hotspot/share/prims/jvmtiExport.c
On Sat, 7 Oct 2023 06:31:08 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvmti.xml line 13044:
>>
>>> 13042:
>>> 13043: >> 13044: id="VirtualThreadStart"
>>> const="JVMTI_EVENT_VIRTUAL_THREAD_START" num="87" phase="start" since="21">
>>
>> Does "filtered" mean that the event
On Sun, 8 Oct 2023 21:51:42 GMT, Christoph Langer wrote:
> Add listings for linux-ppc64le and aix-ppc64 for the 4 already problem listed
> jstat tests.
Looks good.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16095#pullr
On Sat, 7 Oct 2023 00:49:09 GMT, Alex Menkov wrote:
>> This is subtask of JDK-8299426: Heap dump does not contain virtual Thread
>> stack references
>> The change:
>> - reorganize thread-related code/prepare it to use for unmounted vthreads:
>> - new ThreadDumper class caches stack frames, thr
On Thu, 5 Oct 2023 05:32:20 GMT, Leonid Mesnik wrote:
> Updated test to use createTesJvm.
> Removed internal timeout to not fail when Xcomp is used and also to get more
> info if the test times out.,
>
> Tested by running tier1, hs-tier5 and executing test with various VM flags.
This pull requ
On Fri, 6 Oct 2023 19:55:59 GMT, Leonid Mesnik wrote:
> The launcher class is fixed.
> Tested by tier1 and running test with different VM flags
This pull request has now been integrated.
Changeset: 5b311f20
Author:Leonid Mesnik
URL:
https://git.openjdk.org/jdk/commit/5b311f20dfaed0
>From studying test failures, it looks like the way the test identifies its
>related processes is failing.
It checks the mainArgs of a process by attaching, and looks like it
occasionally misses getting a valid match. The hasMainArgs method ignores
exceptions as it is expecting some exceptions:
On Fri, 6 Oct 2023 20:47:22 GMT, Leonid Mesnik wrote:
> Test fixed to accept vm flags.
Looks good.
So the classPath did not need setting here anyway? I see createTestJvm ends up
adding VM and JAVA options, but I don't see classpath in those. This change
works for me.
Separately I will have
On Fri, 6 Oct 2023 20:47:22 GMT, Leonid Mesnik wrote:
> Test fixed to accept vm flags.
test/jdk/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java line 311:
> 309: private void executeJava() throws Throwable {
> 310: String className = JavaProcess.class.getName();
On Fri, 6 Oct 2023 19:55:59 GMT, Leonid Mesnik wrote:
> The launcher class is fixed.
> Tested by tier1 and running test with different VM flags
Marked as reviewed by kevinw (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/16079#pullrequestreview-1663928691
25 matches
Mail list logo
