Question re safepoints and monitors

[David Holmes]

On 12/01/2012 11:01 PM, Andrew Haley wrote:
> On 01/12/2012 12:39 PM, David Holmes wrote:
>> Yes it is - the interpreter executes the monitorenter() call inside a
>> CALL_VM macro which checks for the pending exception.
>
> Thanks, but I still don't quite get it.
>
> The interrupting thread calls send_thread_stop(), which sets
> thread._pending_async_exception:
>
>    void set_pending_async_exception(oop e) {
>      _pending_async_exception = e;
>      _special_runtime_exit_condition = _async_exception;
>      set_has_async_exception();
>    }
>
> As far as I can see the code that actually reads
> thread._pending_async_exception and sets thread._pending_exception is
> JavaThread::check_and_handle_async_exceptions():
>
>    // Check for pending async. exception
>    if (_pending_async_exception != NULL) {
>      // Only overwrite an already pending exception, if it is not a threadDeath.
>      if (!has_pending_exception() || !pending_exception()->is_a(SystemDictionary::ThreadDeath_klass())) {
>
>        // We cannot call Exceptions::_throw(...) here because we cannot block
>        set_pending_exception(_pending_async_exception, __FILE__, __LINE__);
>
> but check_and_handle_async_exceptions() is not called in the case of a
> monitor operation.  We need something to copy _pending_async_exception
> to _pending_exception, but I can't see when that would ever be called.

Yes I think you are correct. The exception will remain as a pending 
async exception until the next thread state transition that causes 
handle_special_runtime_exit_condition to be called (or there may be some 
other path that forces an async check - like the next safepoint).

There is a lot of history to the way Thread.stop operates ...

David
-----


> Andrew.