8185853: Generate readability graph at link time and other startup improvements

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

8185853: Generate readability graph at link time and other startup improvements

Alan Bateman
This is a patch for jdk10/jdk10 to claw back some of the regression to
startup performance in JDK 9 for very short lived applications.

The bulk of the changes are to the "system modules" jlink plugin and the
related code in the module system initialization. Specifically, the
plugin now generates code to create the readability graph for initial
modules known at link time This allows resolution to be skipped at
startup for common cases, it also avoids needing to reconstitute the
module descriptors for modules that will not be resolved (the EE modules
when the initial module is the class path for example). The system
module finder has been significantly changed as part of this but all the
execution scenarios (images, exploded builds, images patched with
exploded build, etc.) that are needed in differetnt JDK development
scenarios work as before.

The patch also includes a few misc. changes to reduce the number of
class loaded during startup and also some local tuning. There is also a
change to the class path initialization to re-fix JDK-6760902 so that
lookup of resources on the boot loader append path (-Xbootclasspath/a)
is aligned with class loading in the VM in the way that it skips empty
path elements. This follows the restoration of tests that Mandy pushed a
few days ago with JDK-8185541.

The webrev with the changes is here:
   http://cr.openjdk.java.net/~alanb/8185853/webrev/index.html

-Alan.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8185853: Generate readability graph at link time and other startup improvements

Mandy Chung


On 8/4/17 8:48 AM, Alan Bateman wrote:

> This is a patch for jdk10/jdk10 to claw back some of the regression to
> startup performance in JDK 9 for very short lived applications.
>
> The bulk of the changes are to the "system modules" jlink plugin and
> the related code in the module system initialization. Specifically,
> the plugin now generates code to create the readability graph for
> initial modules known at link time This allows resolution to be
> skipped at startup for common cases, it also avoids needing to
> reconstitute the module descriptors for modules that will not be
> resolved (the EE modules when the initial module is the class path for
> example). The system module finder has been significantly changed as
> part of this but all the execution scenarios (images, exploded builds,
> images patched with exploded build, etc.) that are needed in
> differetnt JDK development scenarios work as before.
>
> The patch also includes a few misc. changes to reduce the number of
> class loaded during startup and also some local tuning. There is also
> a change to the class path initialization to re-fix JDK-6760902 so
> that lookup of resources on the boot loader append path
> (-Xbootclasspath/a) is aligned with class loading in the VM in the way
> that it skips empty path elements. This follows the restoration of
> tests that Mandy pushed a few days ago with JDK-8185541.
>
> The webrev with the changes is here:
>   http://cr.openjdk.java.net/~alanb/8185853/webrev/index.html

It is good to see more optimization be done at link time that improves
the startup.

jdk/internal/loader/ClassLoaders.java

79 if (cp.length() == 0) cp = null;

Our launcher and hotspot VM always set "java.class.path" system property
and so it'll be non-null.  It might help the readers to check if (cp !=
null && cp.length() == 0).

jdk/internal/module/SystemModulesMap.java

128 Constructor<?> ctor = Class.forName(cn).getConstructor();

Class.forName(Module, String) will only search the specified module.  No
performance difference since the class exists in java.base but it may
make it clear to the readers.

jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
    This generates one SystemModules for each module that has a main
class.  A user may create a launcher at link time but specifies a main
class which may be different to the one in the module descriptor.   A
possible future enhancement is to generate a SystemModules for the main
class if the launcher is created by jlink.

Otherwise, this patch looks good.

Mandy

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8185853: Generate readability graph at link time and other startup improvements

Alan Bateman
On 06/08/2017 01:37, mandy chung wrote:
>
> It is good to see more optimization be done at link time that improves
> the startup.
>
> jdk/internal/loader/ClassLoaders.java
> 79 if (cp.length() == 0) cp = null;
> Our launcher and hotspot VM always set "java.class.path" system
> property and so it'll be non-null.  It might help the readers to check
> if (cp != null && cp.length() == 0).
Fair point, there is an assumption that the VM is created with either an
initial module or a class path and HotSpot masks that to some extent. So
yes, clearer if we use the above.

>
> jdk/internal/module/SystemModulesMap.java
> 128 Constructor<?> ctor = Class.forName(cn).getConstructor();
> Class.forName(Module, String) will only search the specified module.  
> No performance difference since the class exists in java.base but it
> may make it clear to the readers.
The loaded classes haven't been patched to be members of java.base at
this point in the startup so there isn't a Module object to use the
2-arg forName. But yes, a comment might help here.

>
> jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>    This generates one SystemModules for each module that has a main
> class.  A user may create a launcher at link time but specifies a main
> class which may be different to the one in the module descriptor.   A
> possible future enhancement is to generate a SystemModules for the
> main class if the launcher is created by jlink.
Yes, I've been thinking about this too and I think it will require a
clean way for jlink to expose the details of launchers to plugins.

> Otherwise, this patch looks good.
Thanks for spending time on this.

-Alan
Loading...