As a candidate for replacing C2 (and C1), Graal should have the following characteristics:
* fast startup
* compile time similar to native compilers
* memory usage disjoint from the application Java heap
* bulk de-allocation of memory used during a single compilation
* no profile pollution of JDK code used by the application
The best way to achieve this is to compile Graal with SubstrateVM (SVM) into a shared library (libgraal) that can be linked to HotSpot.
Desirable features:
1. Graal should be deployable in both its current form (JavaGraal) as well as libgraal in a single VM execution. This allows for easier development of Graal (debugging Graal with Java IDEs is easier than debugging with gdb). This will be particularly important once the native compilers are removed. For example, libgraal is the first tier JIT and JavaGraal is the top tier JIT (or vice versa).
2. The memory allocated for a compilation should be bulk deallocated once compilation is done. This means data structures such as the snippet caches will need to be allocated differently somehow.
Note that this will may make backwards incompatible changes to JVMCI.
* fast startup
* compile time similar to native compilers
* memory usage disjoint from the application Java heap
* bulk de-allocation of memory used during a single compilation
* no profile pollution of JDK code used by the application
The best way to achieve this is to compile Graal with SubstrateVM (SVM) into a shared library (libgraal) that can be linked to HotSpot.
Desirable features:
1. Graal should be deployable in both its current form (JavaGraal) as well as libgraal in a single VM execution. This allows for easier development of Graal (debugging Graal with Java IDEs is easier than debugging with gdb). This will be particularly important once the native compilers are removed. For example, libgraal is the first tier JIT and JavaGraal is the top tier JIT (or vice versa).
2. The memory allocated for a compilation should be bulk deallocated once compilation is done. This means data structures such as the snippet caches will need to be allocated differently somehow.
Note that this will may make backwards incompatible changes to JVMCI.
- duplicates
-
JDK-8223220 JVMCI based JIT Compiler pre-compiled as shared library
- Draft
- is blocked by
-
JDK-8211652 Update JVMCI to support JVMCI based Compiler compiled into shared library
- Closed
- relates to
-
JDK-8196611 [Graal] Tests unaware of objects allocation triggered by Graal
- Open
-
JDK-8204855 [JVMCI][Graal] make JVMCI API changes necessary to support libgraal
- Closed