RFR: 8308614: Enabling JVMTI ClassLoad event slows down vthread creation by factor 10

[Serguei Spitsyn]

This is a fix of a performance/scalability related issue. The `JvmtiThreadState` objects for virtual thread filtered events enabled globally are created eagerly because it is needed when the `interp_only_mode` is enabled. Otherwise, some events which are generated in `interp_only_mode` from the debugging version of interpreter chunks can be missed.
However, it has to be okay to avoid eager creation of these object if no `interp_only_mode` has ever been requested.
It seems to be an extremely important optimization to create JvmtiThreadState objects lazily in such cases.
It is done by introducing the flag `JvmtiThreadState::_seen_interp_only_mode` which indicates when the `JvmtiThreadState` objects have to be created eagerly.

Additionally, the fix includes the following related changes:
 - Use condition double checking idiom for `MutexLocker mu(JvmtiThreadState_lock)` in the function `JvmtiVTMSTransitionDisabler::VTMS_mount_end` which is on a performance-critical path and looks like this:

  JvmtiThreadState* state = thread->jvmti_thread_state();
  if (state != nullptr && state->is_pending_interp_only_mode()) {
    MutexLocker mu(JvmtiThreadState_lock);
    state = thread->jvmti_thread_state();
    if (state != nullptr && state->is_pending_interp_only_mode()) {
      JvmtiEventController::enter_interp_only_mode();
    }
  }


 - Add extra check of `JvmtiExport::can_support_virtual_threads()` when virtual thread mount and unmount are posted.
 - Minor: Added a `ThreadsListHandle` to the `JvmtiEventControllerPrivate::enter_interp_only_mode`. It is needed because of the dynamic creation of compensating carrier threads which is racy for JVMTI `SetEventNotificationMode` implementation.

Performance mesurements:
- Without this fix the test provided by the bug submitter gives execution numbers:
  - no ClassLoad events enabled:     3251 ms
  - ClassLoad events are enabled: 40534 ms
  
- With the fix:
  - no ClassLoad events enabled:    3270 ms
  - ClassLoad events are enabled:   3385 ms
  
Testing:
 - Ran mach5 tiers 1-6, no regressions are noticed

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

Commit messages:
 - 8308614: Enabling JVMTI ClassLoad event slows down vthread creation by factor 10

Changes: https://git.openjdk.org/jdk/pull/16686/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16686&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308614
  Stats: 37 lines in 3 files changed: 24 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16686/head:pull/16686

PR: https://git.openjdk.org/jdk/pull/16686