RFR: 8263191: Consolidate ThreadInVMfromJavaNoAsyncException and ThreadBlockInVMWithDeadlockCheck with existing wrappers

patricio.chilano.mateo at oracle.com patricio.chilano.mateo at oracle.com
Tue Mar 9 20:32:28 UTC 2021


Hi Dan,

Thanks for looking at this.

On 3/9/21 12:53 PM, Daniel D.Daugherty wrote:
> I think there are non-trivial differences between the old ThreadBlockInVM
> and the new ThreadBlockInVM. Maybe I'm wrong, but they do not look
> equivalent to me.
>
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 155:
>
>> 153:   bool _check_asyncs;
>> 154:  public:
>> 155:   ThreadInVMfromJava(JavaThread* thread, bool check_async = true) : ThreadStateTransition(thread), _check_asyncs(check_async) {
> Field is `_check_asyncs` and parameter is `check_async`.
> Either add an `s` to the parameter or delete the `s` from the field.
>
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 237:
Fixed.


>> 235:
>> 236:  public:
>> 237:   ThreadBlockInVM(JavaThread* thread, Mutex** in_flight_mutex_addr = NULL)
> The new ThreadBlockInVM is not equivalent to the old one.
> The old one used `trans(_thread_in_vm, _thread_blocked)` which
> asserted that the "from" state is equal to `_thread_in_vm`. This
> new code does not do that.
Fixed. I added an assert() that the thread state is _thread_in_vm in 
TBIVM() and _thread_blocked in ~TBIVM().


> The trans() call also resulted in a
> `SafepointMechanism::process_if_requested(thread);` call after
> we transitioned the thread to `_thread_in_vm`+1 and before we
> set the new thread state to `_thread_blocked`.
>
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 242:
>
>> 240:     // Once we are blocked vm expects stack to be walkable
>> 241:     thread->frame_anchor()->make_walkable(thread);
>> 242:     thread->set_thread_state(_thread_blocked);
> If you're going to set the thread_state directly here, I think you need
> to keep the `OrderAccess::storestore()` call. However, this new ThreadBlockInVM
> is also missing a `SafepointMechanism::process_if_requested(thread)` call that
> happened before setting the `_thread_blocked` state.
Calling explicitly SafepointMechanism::process_if_requested() in TBIVM() 
is not needed because we are setting the state to blocked. That will 
already allow any safepoint/handshake to proceed. If when reaching 
~TBIVM() the poll is armed then we will go through 
process_if_requested() there.
The reason I removed OrderAccess::storestore() is because 
thread->set_thread_state() is a release store already.


Thanks,
Patricio
> -------------
>
> Changes requested by dcubed (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/2880



More information about the hotspot-runtime-dev mailing list