RFR: 8269592: [JVMCI] Optimize c2v_iterateFrames

[Dean Long]

On Thu, 8 Jul 2021 19:19:37 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Several smaller optimizations and cleanups to JVMCI's iterateFrames:
>> * Restructure the iterateFrames method for better readability and maintenance, with some parts extracted to helper functions.
>> * Use vframeStream as the iterator for faster iteration in case not every vframe matches the method filter, so we can avoid creating javaVFrames for skipped vframes. We use vframeStream::asJavaVFrame() to get the current javaVFrame.
>> * Extended vframeStream::asJavaVFrame() to also work with native frames, so that it works with all java frames returned by vframeStream. This way, native compiledVFrames will just work and do not need extra handling.
>> Test coverage is provided via a newly added iterateFrames jtreg test that includes a JNI call on the stack.
>> * Added two trivial getters to vframeStream: vframe_id() and decode_offset().
>> These are used together with compiledVFrame::at_scope() to avoid going through vframeStream::asJavaVFrame() and recreating the scope objects for every matched inlined vframe of a compiled frame which would be more expensive than using javaVFrame::sender() (that shares the scope object pool).
>> * Only resolve the callback interface method once per iterateFrames call.
>> * Only resolve the Method* of the ResolvedJavaMethods to be matched once per iterateFrames call.
>> * Only allocate localIsVirtual array if at least one local is virtual (the Java part already expects this).
>> * Use matched ResolvedJavaMethod instances instead of going through JVMCIEnv::get_jvmci_method, if possible.
>
> We went through a bunch of review and tests cycles on this in our JDK repos so this is the result of that, so I've approved it.  @dean-long saw some of this progress as well.
> So you want an ifdef JVMCI around the is_native part of the guarantees?  Why are those guarantees anyway?  Seems like they should just be asserts to me.

@tkrodriguez I think I introduced those guarantees, and now I agree they should probably be asserts.

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

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