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 >
