RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3]
Doug Simon
dnsimon at openjdk.java.net
Tue Apr 19 10:17:14 UTC 2022
> Currently, libgraal 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.
>
> This PR implements the following solution to these problems:
> 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.
>
> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object.
Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8262/files
- new: https://git.openjdk.java.net/jdk/pull/8262/files/fc9dd87f..8aacbbaa
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=01-02
Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
Patch: https://git.openjdk.java.net/jdk/pull/8262.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262
PR: https://git.openjdk.java.net/jdk/pull/8262
More information about the hotspot-dev
mailing list