jjs and the tiny heap that couldn't

[Claes Redestad]

Hi,

as I was playing around with jjs to get some data points on recent indy
bootstrap improvements when I noticed that the default heap size might
be excessively small (linux x64 on a machine with 64G RAM):

exit.js:
exit();

jdk9/bin/jjs -J-Xlog:gc exit.js
[0.026s][info][gc] Using G1
[0,246s][info][gc] GC(0) Pause Young (G1 Evacuation Pause) 3M->0M(8M) 
(0,243s, 0,246s) 3,643ms
[0,321s][info][gc] GC(1) Pause Young (G1 Evacuation Pause) 2M->1M(8M) 
(0,314s, 0,321s) 6,996ms
[0,353s][info][gc] GC(2) Pause Young (G1 Evacuation Pause) 2M->1M(8M) 
(0,349s, 0,353s) 3,307ms
[0,485s][info][gc] GC(3) Pause Young (G1 Evacuation Pause) 3M->1M(8M) 
(0,474s, 0,485s) 10,991ms
[0,581s][info][gc] GC(4) Pause Young (G1 Evacuation Pause) 3M->2M(14M) 
(0,573s, 0,581s) 7,879ms
[0,743s][info][gc] GC(5) Pause Young (G1 Evacuation Pause) 6M->2M(14M) 
(0,735s, 0,743s) 8,678ms

It appears jjs starts out with a tiny heap, leading to substantial
time spent in GC just to bootstrap.

A small bump to -Xms35m removes GC activity during bootstrap (for
reference on this machine java defaults to an -Xms around 140m):

jdk9/bin/jjs -J-Xmx35m -J-Xlog:gc exit.js
[0.026s][info][gc] Using G1

The story is similar on 8u, but there I had to increase it all the way
to -Xms100m to get GC activity down to zero.

Is it just me, or does it seem odd that jjs is so aggressively tuned
for minimal footprint that we spend considerable time in GC just to get
up and running - and still end up increasing the heap size in the
process?

Thanks!

/Claes