Epsilon + Graal

Aleksey Shipilev shade at redhat.com
Thu Apr 11 09:40:13 UTC 2019


I am tinkering with Epsilon support for Graal (targeting AOT binaries with no GC). This patch
applies to jdk/jdk:

...and passes this test suite:

$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=compiler/aot
TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC"

...and does this:

$ build/linux-x86_64-server-release/images/jdk/bin/jaotc -J-XX:+UseEpsilonGC --info HelloWorld.class
--output hello-epsilon.so
$ build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions
-XX:+UseEpsilonGC -Xlog:gc -XX:+UseAOT -XX:AOTLibrary=./hello-epsilon.so  HelloWorld
[0.004s][info][gc] Resizeable heap; starting at 2009M, max: 30718M, step: 128M
[0.004s][info][gc] Using TLAB allocation; max: 4096K
[0.004s][info][gc] Elastic TLABs enabled; elasticity: 1.10x
[0.004s][info][gc] Elastic TLABs decay enabled; decay time: 1000ms
[0.004s][info][gc] Using Epsilon
[0.038s][info][gc] Heap: 30718M reserved, 2009M (6.54%) committed, 698K (0.00%) used

real	0m0.048s
user	0m0.064s
sys	0m0.014s

I am confused what to do next. Some process questions:

 a) Where do I propose the patch? As GitHub PR to oracle/graal, is that right?
 b) The change requires adjustments in JVMCI, how is that handled? I assume JVMCI and Graal changes
are done independently? In that case, there is a bit of circularity here: I cannot put JVMCI change
in without breaking runs with Epsilon for a while, and cannot put Epsilon changes in before JVMCI is
 c) Pretty sure current patch fails some write barrier verification, because verification assumes
either G1 or CardTable-based BarrierSet. Do we expect to clean up verification before the Epsilon
patch, or can it be done within the patch?
 d) How do we run Graal tests (especially given the need for JVMCI adjustments)? Are they run
automatically on PR proposal?


More information about the graal-dev mailing list