I don't think jjs was ever GC tuned! Most likely default copied/adapted from somewhere else!
Please file a bug with your findings. PS. jjs of jdk9 is very different (in interactive mode) from that of jdk8u. jdk9 versions on jline+many other desktop stuff and so would load lot more code. Thanks, -Sundar On 8/26/2016 5:54 AM, Claes Redestad wrote: > 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
