-
Enhancement
-
Resolution: Fixed
-
P4
-
15, 19
-
b20
Currently, libgraal (i.e. Graal compiled by Native Image to libjvmcicompiler.so) runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems:
1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle.
2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens.
The proposed solution is as follows:
1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread.
2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive.
1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle.
2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens.
The proposed solution is as follows:
1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread.
2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive.
- relates to
-
JDK-8286063 check compiler queue after calling AbstractCompiler::on_empty_queue
- Resolved
-
JDK-8293019 [JVMCI] change ratio of libgraal to C1 threads and use one isolate per libgraal thread
- Resolved