On Mon, 13 Jun 2022 11:42:43 GMT, David Holmes wrote:
> Maybe we actually need to backtrack and restore an invariant that there is
> always a TLH even for the current thread and fix the JVMTI code that did
> things differently?
This will make JVMTI code unnecessarily ugly in a couple of spots.
On Mon, 13 Jun 2022 07:45:41 GMT, Robbin Ehn wrote:
>> Johan Sjölén has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move assert up and remove other assert, remove unused var
>
> The only way to become an active handshaker is to handshake
On Tue, 7 Jun 2022 12:42:05 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and i
On Tue, 7 Jun 2022 12:42:05 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and i
> Please review this PR for fixing JDK-8287281.
>
> If a thread is handshake safe we immediately execute the closure, instead of
> going through the regular Handshake process.
>
> Finally: Should `VirtualThreadGetThreadClosure` and its `do_thread()` body
> be inlined instead? We can do this i
On Mon, 6 Jun 2022 16:36:01 GMT, Daniel D. Daugherty wrote:
>> We also no longer need L358 as `current` is now unused.
>
> JavaThread *target = state->get_thread();
> Thread *current = Thread::current();
>
> assert(state != NULL, "sanity check");
>
> The `assert()` on L360 is in the wrong p
On Tue, 7 Jun 2022 09:58:11 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and i
> Please review this PR for fixing JDK-8287281.
>
> If a thread is handshake safe we immediately execute the closure, instead of
> going through the regular Handshake process.
>
> Finally: Should `VirtualThreadGetThreadClosure` and its `do_thread()` body
> be inlined instead? We can do this i
On Mon, 6 Jun 2022 07:15:45 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call Handshake::execute
>> - Switch or
On Mon, 6 Jun 2022 07:20:10 GMT, David Holmes wrote:
>> src/hotspot/share/prims/jvmtiEventController.cpp line 370:
>>
>>> 368: }
>>> 369: EnterInterpOnlyModeClosure hs;
>>> 370: assert(state->get_thread() != NULL, "sanity check");
>>
>> Existing: We have already performed this check. We s
On Mon, 6 Jun 2022 07:17:15 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call Handshake::execute
>> - Switch or
On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and i
On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and i
On Mon, 6 Jun 2022 07:19:06 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call Handshake::execute
>> - Switch or
On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and i
On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and i
On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> I chose a different solution than the one suggested. Looking at all callers
>> of `Handshake::execute`, it seems that only one depends on `target ==
>> current`. The rest special case th
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by calling `is_handshake_safe_for` and
> `do_thread` dir
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by calling `is_handshake_safe_for` and
> `do_thread` dir
On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sjölén wrote:
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by calling `is_handshake_safe_for` and
> `do_thread` dir
Please review this PR for fixing JDK-8287281.
I chose a different solution than the one suggested. Looking at all callers of
`Handshake::execute`, it seems that only one depends on `target == current`.
The rest special case that by calling `is_handshake_safe_for` and `do_thread`
directly. I co
On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sjölén wrote:
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by
23 matches
Mail list logo
