Skip methods with JvmtiMountTransition annotation in findDecompileInfo

[babsingh]

Java methods tagged with the JvmtiMountTransition annotation are
involved in transitioning between carrier to virtual threads, and
vice-versa.

These methods are not part of the thread's scope. So, they are skipped
during introspection by the following JVMTI functions:

• ForceEarlyReturn
• NotifyFramePop
• Local Variable (GetOrSetLocal)

This PR allows us to match the RI in jvmti/vthread/MethodExitTest.

Related #17490

Closes #17758

[babsingh]

@gacholio Requesting your review. This replaces #17758 and includes your feedback.

[gacholio]

Ah, findDecompileInfo is a misleading name. I believe this is OK.

[gacholio]

Are the stack trace APIs not affected by the annotation?

[babsingh]

Are the stack trace APIs not affected by the annotation?

The JvmtiMountTransition annotation only impacts JVMTI functions. It doesn't impact other stack trace APIs.

[gacholio]

The JvmtiMountTransition annotation only impacts JVMTI functions. It doesn't impact other stack trace APIs.

There are stack trace APIs in JVMTI - the depth of frames will now not match (i.e. get a stack trace, find a method at depth 3, then try to use one of the APIs modified here, and fail because the depth is off due to an annotated method).

[gacholio]

jenkins test sanity alinux64 jdk21

[babsingh]

There are stack trace APIs in JVMTI - the depth of frames will now not match (i.e. get a stack trace, find a method at depth 3, then try to use one of the APIs modified here, and fail because the deoth is off due to an annotated method).

Yes. We will need to apply this change to all places where walkStackFrames is used in JVMTI functions. Will address this in a follow up PR.

Previously, I confused it with the Java stack trace APIs.