On Sat, 18 Feb 2023 07:56:25 GMT, Alan Bateman wrote:
>>> Thanks for dropping is_bound_vthread, I think it's much better now. What
>>> would you think about changing it to test the thread type is_a
>>> vmClasses::BaseVirtualThread_klass() so the VM doesn't need to know about
>>> ThreadBuilders
On Fri, 17 Feb 2023 19:54:08 GMT, Patricio Chilano Mateo
wrote:
> Yes, we could do that. Although I think that checking for
> BoundVirtualThread_klass is more descriptive of what we are trying to do and
> will be less confusing when reading the code. How about checking for
> `(!VMContinuation
On Fri, 17 Feb 2023 16:07:50 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Fri, 17 Feb 2023 16:07:50 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Fri, 17 Feb 2023 17:28:19 GMT, Alan Bateman wrote:
> Thanks for dropping is_bound_vthread, I think it's much better now. What
> would you think about changing it to test the thread type is_a
> vmClasses::BaseVirtualThread_klass() so the VM doesn't need to know about
> ThreadBuilders$BoundVi
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
> shouldn't include virtual threads in the results (GetAllThreads,
> G
On Fri, 17 Feb 2023 08:23:13 GMT, Serguei Spitsyn wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - restore state should be only for VirtualThreads
>> - add suspend check
>
> test/hotspot/jtreg/serviceab
On Fri, 17 Feb 2023 08:29:53 GMT, Serguei Spitsyn wrote:
> The fix looks good to me. Thank you for the update. I'm not sure if you
> wanted to get rid of `is_bound_vthread` though. Just want to know you
> intention. Thanks, Serguei
>
Great. Yes, I just removed is_bound_vthread, please take a lo
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
> shouldn't include virtual threads in the results (GetAllThreads,
> G
On Thu, 16 Feb 2023 17:03:32 GMT, Patricio Chilano Mateo
wrote:
> Yes, the elist comment was related to the other issue. The reason why I
> didn't explicitly added this check is because it will we done in the
> suspend/resume call already (while holding the handshake lock which
> serializes t
On Thu, 16 Feb 2023 16:59:05 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Thu, 16 Feb 2023 16:59:05 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Thu, 16 Feb 2023 07:48:16 GMT, Serguei Spitsyn wrote:
> The `SuspendAllVirtualThreads` spec has this statement:
>
> ```
> Suspend all virtual threads except those in the exception list.
> Virtual threads that are currently suspended do not change state.
> ```
>
> And the `ResumeAllVirtua
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
> shouldn't include virtual threads in the results (GetAllThreads,
> G
On Wed, 15 Feb 2023 20:53:23 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/prims/jvmtiEnv.cpp line 1045:
>>
>>> 1043: JvmtiEnvBase::is_vthread_alive(vt_oop) &&
>>> 1044: !JvmtiVTSuspender::is_vthread_suspended(vt_oop)) ||
>>> 1045: java_thread->is_b
On Wed, 15 Feb 2023 05:04:21 GMT, Serguei Spitsyn wrote:
> Patricio, The fix looks pretty solid to me. I've already posted one comment
> and will post a couple of formatting nits. I agree with Alan, it'd be nice to
> get rid of `is_bound_vthread` if possible. I will make one more pass after
>
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
> shouldn't include virtual threads in the results (GetAllThreads,
> G
On Wed, 15 Feb 2023 01:22:33 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Wed, 15 Feb 2023 01:22:33 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Wed, 15 Feb 2023 01:22:33 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Tue, 14 Feb 2023 22:31:43 GMT, Leonid Mesnik wrote:
> I've left one comment. Otherwise test changes looks good to me.
>
Thanks for the review Leonid!
> test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/BoundVThreadTest.java
> line 27:
>
>> 25: * @test
>> 26: * @summary Veri
On Tue, 14 Feb 2023 14:20:30 GMT, Alan Bateman wrote:
> The changes in the updates look good. I think the main thing to decide on is
> whether JavaThread:: _is_bound_vthread is needed or not. If
> GetCurrentThreadCpuTime is changed to allow an implementation support this
> function then it loo
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
> shouldn't include virtual threads in the results (GetAllThreads,
> G
On Mon, 13 Feb 2023 19:51:12 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Mon, 13 Feb 2023 19:51:12 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Sat, 11 Feb 2023 07:31:00 GMT, Alan Bateman wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - use different @test to run with -XX:-VMContinuations
>> - more removals of @requires vm.continuations
>>
On Mon, 13 Feb 2023 19:51:12 GMT, Patricio Chilano Mateo
wrote:
>> Please review the following change. Some of the JVMTI functions had to be
>> modified since they are not supported by the specs on virtual threads
>> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
>
On Sat, 11 Feb 2023 07:37:34 GMT, Alan Bateman wrote:
> On tests, there are a few other tests that can be changed to drop `@requires
> vm.continuations`, e.g. the jshell tests that run with --enable-preview
> should no longer need the `@requires`. There are also a few JDI and at least
> one Ap
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime,
> PopFrame, ForceEarlyReturnXXX) or shouldn't include virtual threads in t
On Fri, 10 Feb 2023 14:50:36 GMT, Patricio Chilano Mateo
wrote:
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid
> repeating the check, I mainly added it to avoid transitioning for
> GetCurrentThreadCpuTime (we are native and cannot access oops).
The timer funct
On Fri, 10 Feb 2023 14:50:36 GMT, Patricio Chilano Mateo
wrote:
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime,
> PopFr
On Fri, 10 Feb 2023 14:50:36 GMT, Patricio Chilano Mateo
wrote:
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime,
> PopFr
32 matches
Mail list logo
