Epsilon + Graal

[Doug Simon]

Hi Aleksey,

It would be great to see support for Epsilon in Graal.

More inline below:

> On 11 Apr 2019, at 11:40, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Hi,
> 
> I am tinkering with Epsilon support for Graal (targeting AOT binaries with no GC). This patch
> applies to jdk/jdk:
>  http://cr.openjdk.java.net/~shade/epsilon/graal-support.patch
> 
> ...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
> 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?

Yes, that’s where the Graal changes should go.

> 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
> updated?

I think you can make the Graal changes independently of the JVMCI changes with this in GraalHotSpotVMConfig:

    public final boolean useEpsilonGC = getFlag("UseEpsilonGC", Boolean.class, false);

That means the JVMCI patch can be submitted separately.

> 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?

Roman has volunteered to look into this so hopefully you can co-ordinate with him. I don’t see any problem with doing it all in one PR.

> d) How do we run Graal tests (especially given the need for JVMCI adjustments)? Are they run
> automatically on PR proposal?

There are a few tests run in the Travis gate on a GitHub PR but I doubt these would be enough for what you want. We perform a bunch more testing when integrating a Graal PR internally. Any issues discovered there will be post to the GitHub PR, hopefully with commands to reproduce.

One process option is to submit a normal JDK webrev with both JVMCI and Graal changes at the same time as submitting a Graal GitHub PR. This allows you to do whatever testing you want in the normal OpenJDK workflow. During the periodic Graal syncs to OpenJDK (which are thankfully becoming more frequent thanks to Jesper Wilhelmsson) , the Graal changes in OpenJDK will simply be overwritten.

Hope that helps!

-Doug