-
Enhancement
-
Resolution: Fixed
-
P4
-
19, 20
-
b05
The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to read libjvmci objects, it requires 4 VM transitions:
1. HotSpot: VM to native (_thread_in_vm -> _thread_in_native)
2. SVM: Native to VM (entering SVM)
3. SVM: VM to native (exiting 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.
There are other inefficiencies in the JVMCI Java/C++ interactions such as a VM round trip to create the class name string when converting a Klass* value to a ResolvedJavaType value.
This issue exists to remove or reduce the above inefficiencies.
1. HotSpot: VM to native (_thread_in_vm -> _thread_in_native)
2. SVM: Native to VM (entering SVM)
3. SVM: VM to native (exiting 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.
There are other inefficiencies in the JVMCI Java/C++ interactions such as a VM round trip to create the class name string when converting a Klass* value to a ResolvedJavaType value.
This issue exists to remove or reduce the above inefficiencies.
- relates to
-
JDK-8290234 [JVMCI] use JVMCIKlassHandle to protect raw Klass* values from concurrent G1 scanning
-
- Resolved
-
-
-
- New
-
-
-
- Resolved
-
-
-
- Resolved
-
(1 links to)