Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).

To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size. The current implementation set the stack limit to 10 Java frames. Observing this limit is important because:

* when running in release mode, anything above 10 frames will just be discarded (meaning that if a scoped method is "deeper" we might just miss it).
* when running in debug mode we fail with an assertion.

Unfortunately we don't have a direct way to make sure that all the scoped methods in the JDK do indeed execute within those limits. This means that accidental refactoring can push this critical JDK code over the threshold.

To address this, we should write a test that calls a scoped method and attempts to determine the maximum stack depth associated with that method.

Using a bytecode inspection approach (i.e. classfile API) is possible - but will miss a lot of interesting and non-deterministic cases such as:
* JNI method lookup
* static initializers
* finalizers/cleaners
* whether an intrinsics is applied or not

As a result it would be better for such a test to use a JVMTI agent. Such agent could intercept method entry/exit events, and could record the stack depth associated with a scoped method.