RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition

[Daniel D.Daugherty]

On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which contains the following cleanups:
> 
> - Move _suspend_flags from Thread class to JavaThread
> 
> - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods:  clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception().
> 
> - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. 
> 
> - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR.
> 
> Tested in mach5 tiers 1-6.
> 
> Thanks,
> Patricio

Thumbs up.

It would have been helpful to do the code motion as a separate commit
so the rename of things from Thread -> JavaThread would be easily
comparable from baseline -> commit1. Then do the moves of things
from the Thread area of the files to the JavaThread area of the files in
commit2.

I _think_ I was able to follow and check everything by scrolling back
and forth, but I'm not 100% sure.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3919