RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition [v2]

[Patricio Chilano Mateo]

> 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

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8265934
 - v1

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3919/files
  - new: https://git.openjdk.java.net/jdk/pull/3919/files/b538f995..78ec1068

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3919&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3919&range=00-01

  Stats: 39077 lines in 930 files changed: 19359 ins; 10629 del; 9089 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3919.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3919/head:pull/3919

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