Thanks!
This looks much better than I naively expected, especially w.r.t.
footprint, and I probably wouldn't have asked/suggested what I did if
I'd gotten the attachement the first time around (although I'd prefer
some native memory measurement over "heap-after-GC", this should be
indicative enough).
/Claes
On 2015-10-06 16:34, Mandy Chung wrote:
See http://cr.openjdk.java.net/~mchung/jigsaw/jake-startup.20151005.pdf
Mandy
p.s. In fact the attachment got trimmed.
On Oct 6, 2015, at 7:31 AM, Mandy Chung <mandy.ch...@oracle.com> wrote:
I realize I missed the attachment after seeing Claes’ question. This includes
the heap usage after GC.
On Oct 5, 2015, at 2:13 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
I have been experimenting a jlink plugin to improve the module system startup
time. On a Quad-Core Intel Xeon E5 @3.7 GHz, 16G memory (Mac Pro) machine,
the module system startup takes 110 ms and 75% of it is to reconstitute 64
module descriptors with 2388 packages altogether.
This high overhead includes initializing lambda forms (class loading, linking,
initialization), parsing of module-info.class and compilation of many methods
during startup.
The attached charts shows the summary of module system startup
1) jake-b83 (as of Sep 29)
module bootstrap time 110 ms
module descriptor reconstitution 82 ms
VM startup time is 3x of jdk9-b83 vm startup time (148ms vs 47 ms)
2) No lambda at startup
module bootstrap time 66 ms (saved 44 ms compared to #1)
module descriptor reconstitution 33.6 ms (saved 48.4ms)
VM startup time is 2.2x of jdk9-b83 (105ms vs 47ms)
3) jlink plugin to generate a .class file to build module descriptors at link
time
module bootstrap time 50.7 ms (saved 15.3ms compared to #2)
module descriptor reconstitution 16.8 ms (saved 16.8ms)
VM startup time is 1.9x of jdk9-b83 (90ms vs 47ms)
For #3, it parses module-info.class at link time and validates all names. It
generates a .class file to call a custom Builder to create ModuleDescriptor for
the installed modules. At runtime, the generated class will construct the
Builder and ModuleDescriptor objects will skip name validation, no defensive
copy of the input set/map and skip reading and parsing of module-info.class
(this is done by a special module descriptor builder class that doesn’t use
lambda. This special builder is only used by installed modules).
It saves 15.3 ms (23% of the module system bootstrap time in #2). The
downside of this optimization is a little harder to make change and diagnose
(this plugin implementation is straight forward though). There may be other
small optimization to explore that could be done at jlink time (e.g.
BuiltinClassLoader maintains a package to module map that can be constructed
with a specific size to avoid map resizing).
What’s your thought/opinion to integrate this jlink plugin into jake?
Mandy
