RFR: 8289094: [JVMCI] reduce JNI overhead and other VM rounds trips in JVMCI

[Doug Simon]

On Tue, 28 Jun 2022 07:46:09 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
> 1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
> 2. SVM: Native to VM (enter SVM)
> 3. SVM: VM to native (exit SVM)
> 4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)
> 
> When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
> This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.
> 
> There are other smaller changes to reduce JNI overhead included in this PR:
> * Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
> * Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
> * Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
> * Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.
> 
> This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.

src/hotspot/share/runtime/timer.hpp line 41:

> 39:   elapsedTimer()             { _active = false; reset(); }
> 40:   void add(elapsedTimer t);
> 41:   void add_nanoseconds(jlong ns);

This is required so that code installation work done in libjvmci can be properly [attributed to a VM based timer](https://github.com/openjdk/jdk/pull/9305/files#diff-c8d24aa5ec59cf15ded545e3a34a1546758691a96bfe1342fdcb2aaf9cf9a696R936).

src/hotspot/share/utilities/ostream.hpp line 103:

> 101:    void print_raw_cr(const char* str)         { write(str, strlen(str)); cr(); }
> 102:    void print_raw_cr(const char* str, size_t len){ write(str,         len); cr(); }
> 103:    void print_data(void* data, size_t len, bool with_ascii, bool rel_addr=true);

This allows for hex dumps to show absolute addresses which is important for comparing a buffer [written in Java](https://github.com/openjdk/jdk/pull/9305/files#diff-d290f5a7a572ba7d4f0c7d234eb73de6537a2aa1d02726527d8db0df23c874b7R118-R134) and [read in C++](https://github.com/openjdk/jdk/pull/9305/files#diff-5e4a9ef468fc0f1564d6cfbe98f44b1099842098366cbec4103710137b2022edR34-R36).

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

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