Graal: Is there any plan for GC improvement?

[ziyilin]

We have managed to compile sofa-registry meta( https://github.com/sofastack/sofa-registry/tree/master/server/server/meta) into native image, but found GC performance might be the bottleneck of its future implementation.

Expriment setup: -Xmx1024m -Xms1024m -XX:MaximumYoungGenerationSizePercent=80 -XX:PercentTimeInIncrementalCollection=100

The following figure shows the GC overview of the experiment. Application responded 120,000 requests from local machine in 32 minutes. There are 466 GCs in total and 2 of them are Full GCs which are pointed out by data label. The interval between Full GCs is 20 minutes. The light grey and dark grey areas are heap before and after each GC, and the blue line is the time consumed by each GC.

We can see the GC time shakes, and may reach a few peaks which cause serious pauses of request responding.

Is there any tuning policy we can try? Would EE version be better in GC? Or is there any plan to improve GC in the future?

[cstancu]

Yes, the Native Image GC has much space for improvement and we are working on integrating additional GC algorithms and strategies. There is currently no difference in GC between CE and EE versions.

[ziyilin]

Good to know that. What are the algorithms and strategies you are working on currently? And do you have any roadmap? Thank you.

[SergejIsbrecht]

@ziyilin , you could also try using the EE version with profile guided optimizations. This could lead to less allocations, which in turn will reduce the GCs.

PGO: https://github.com/graalvm/graalvm-demos/tree/master/scala-days-2018/streams#profile-guided-optimizations-with-native-image

[ziyilin]

@SergejIsbrecht This would help decreasing GC happenings, but still would not reduce GC time. On the other hand, executation pathes during profiling time may differ from pathes of actual run time. So I think PGO may provide very limited help in GC.

[christianwimmer]

How did you come up with the options that you specify for the experiment? For example, -XX:PercentTimeInIncrementalCollection=100 means that full GCs are avoided as long as possible. This means that the old generation fill up more, which in turn can increase the maximum pause times because the heap is larger.

We are working on a low latency GC for EE. For the existing GC, there are several medium-effort improvements that would be possible and could help, for example tenuring in the young generation (which can slow down the filling of the old generation).

[ziyilin]

We tried different values to see how application performance was affected by GC. We set -XX:PercentTimeInIncrementalCollection=100 to see what the longest pause would be.

[fniephaus]

I think this can be closed in favor of https://github.com/oracle/graal/issues/2386.