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
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 the
resu
33 matches
Mail list logo
