RFR: 8256382: Use try_lock for hs_err EventLog printing

[Stefan Karlsson]

On Wed, 25 Nov 2020 07:49:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Don't we have to check not only VMError::is_error_reported, but that it is the current thread that is doing the reporting?

I found inspiration for this in this piece of code:
void ThreadsSMRSupport::print_info_on(outputStream* st) {
  // Only grab the Threads_lock if we don't already own it and if we
  // are not reporting an error.
  // Note: Not grabbing the Threads_lock during error reporting is
  // dangerous because the data structures we want to print can be
  // freed concurrently. However, grabbing the Threads_lock during
  // error reporting can be equally dangerous since this thread might
  // block during error reporting or a nested error could leave the
  // Threads_lock held. The classic no win scenario.
  //
  MutexLocker ml((Threads_lock->owned_by_self() || VMError::is_error_reported()) ? NULL : Threads_lock);
Looking at this a bit more I see that the EventLogs typically check this function instead:
  // check to see if fatal error reporting is in progress
  static bool fatal_error_in_progress() { return _first_error_tid != -1; }
which is used to turn off EventLog logging when we crash. Both these variables are set here:
  if (_first_error_tid == -1 &&
      Atomic::cmpxchg(&_first_error_tid, (intptr_t)-1, mytid) == -1) {
...
    // first time
    _error_reported = true;

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

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