RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3]
David Holmes
david.holmes at oracle.com
Thu Nov 5 22:19:33 UTC 2020
On 6/11/2020 4:19 am, Robbin Ehn wrote:
> On Wed, 4 Nov 2020 14:24:00 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
>
>>> Hi Robbin,
>>>
>>> Thanks, for looking at this.
>>>
>>>>>> How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)?
>>>>
>>>> But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right?
>>> Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that.
>>>
>>> Patricio
>>>> Thanks, Robbin
>>>>
>>>>> That works for me.
>>>>> ## Thanks,
>>>>> David
>>
>>> Hi Robbin,
>>>
>>> Thanks, for looking at this.
>>>
>>>>>> How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)?
>>>>
>>>>
>>>> But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right?
>>>> Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that.
>>>
>>> Patricio
>>>
>>>> Thanks, Robbin
>>>>> That works for me.
>>>>> ## Thanks,
>>>>> David
>>
>> Skimming a bit, as far as I can see void ThreadSafepointState::handle_polling_page_exception() should use ThreadInVMfromJava and in the other path ThreadInVMfromJavaNoAsyncException.
>> No?
>
>> @robehn are you okay with SafepointMechanism::process_if_requested_with_exit_check()?
>>
>> Patricio
>
> Yes, with a caveat; I may try to move it later.
>
>> SafepointMechanism::process_if_requested(THREAD);
>> if (THREAD->has_special_runtime_exit_condition()) {
>> THREAD->handle_special_runtime_exit_condition(checkAsyncs);
>> }
>>
>> it says to me that we are missing an appropriate API abstraction to
>> capture why we need these checks in the calling code.
>
> Yes in this is what interfaceSupport.xxx gives us.
> So I would had preferred a method in there or use transition RAII thingies.
> (I argue we would not be using them for side effect, because you should to be in VM to be blocked.
> E.g. blocked in native makes no sense and we have no 'blocked' in java.
> So to me this is just a place where cheat transition because we can get away with it.)
I don't understand what you are referring to here with reference to
being blocked? The version 1 code used the transition helpers in a
standalone/isolated way e.g.:
{
ThreadInVMfromJava tivm;
}
which transitions from Java to VM and back, for absolutely no reason
other than to get the side-effects of doing those transitions.
David
-----
>>
>> Whether there are things presently inside
>> handle_special_runtime_exit_condition that are not relevant to these
>> calls sites (eg. suspend flag) is a different issue.
>>
>> Cheers,
>> David
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/913
>
More information about the hotspot-runtime-dev
mailing list