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

[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

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: add comment for new ThreadsListHandle use

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16686/files
  - new: https://git.openjdk.org/jdk/pull/16686/files/2582ae3d..de36957a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16686&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16686&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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