Speeding up jmod

Claes Redestad claes.redestad at oracle.com
Sun May 1 02:02:06 UTC 2016


Hi,

Alan asked me to take a look at jmod performance (also jlink, but saving 
that for another day), so I set
up a naive benchmark[1] and started profiling.

... and saw nothing really suspicious except that time is split between 
doing I/O and executing native code in
libz.so, which I guess isn't surprising. Oddly enough the only java 
methods that even show up in
profiles are related to writing, so I figured taking a closer look at 
the code for writing output from jmod
wouldn't hurt. Turns out I was wrong, since I soon found that the output 
stream used by JmodTask is
unbuffered...

Applied a trivial patch[2] and results of running the micro with -f 10 
-i 1 -bm ss (which is more or less like
running jmod standalone):

Benchmark                   Mode  Cnt  Score   Error  Units
JmodBenchmark.jmodJavaBase    ss   10  1.966 ± 0.297   s/op # before
JmodBenchmark.jmodJavaBase    ss   10  1.196 ± 0.142   s/op # after

Seems like a notable reduction right there. Timing runs of jmod 
standalone gives analogous results on
real time, but user time is still almost as high.

Poking around further and it's obvious JIT threads are eating a larger 
portion of my cycles now - likely C2 is
ramping up but not having time to get much done in the short life-time 
of jmod, which is mostly spent in
native code anyhow. Switching to running short-running apps with only C1 
can be profitable, especially on
machines with a lot of cores (like the 2x8x2 machine I'm running this 
on), so I ran the numbers:

Again, with time:

Benchmark                   Mode  Cnt  Score   Error  Units
JmodBenchmark.jmodJavaBase    ss   10  1.175 ± 0.147   s/op

real    0m17.140s
user    0m54.868s
sys    0m4.172s

-XX:TieredStopAtLevel=1

Benchmark                    Mode  Cnt  Score   Error  Units
JmodBenchmark.jmodJavaBase  thrpt   10  1.075 ± 0.194  ops/s

real    0m14.810s
user    0m15.556s
sys    0m1.584s

Yep, only running "C1" improves things a lot in this case and on my 
environment.

I suggest accepting the patch[2] as well as switching the jmod runner to 
run with -XX:TieredStopAtLevel=1
or similar. Both are likely needed for most to see any effect on build 
times.

A long term alternative to consider might be to implement a server-based 
jmod akin to the javac server.

Thanks!

/Claes

[1] http://cr.openjdk.java.net/~redestad/scratch/JmodBenchmark.java - 
assumes the java.base directory
of module compiled sources are available in the working directory, which 
I won't include here for obvious
reasons. -XaddExports:jdk.jlink/jdk.tools.jmod=ALL-UNNAMED

[2] http://cr.openjdk.java.net/~redestad/scratch/jmod_buff.01/



More information about the jigsaw-dev mailing list