RFR: 8150044: Generate classlists at build-time

Erik Joelsson erik.joelsson at oracle.com
Wed May 4 14:11:34 UTC 2016

Build changes look ok to me, but I also helped write most of them.

This certainly adds some build complexity and might seem overly so for 
just this optimization. As I understand it, the plan is to expand this 
build time profiling concept to generate more profile data that can be 
used by for example jlink plugins.


On 2016-05-04 15:36, Claes Redestad wrote:
> Hi,
> please review this change to generate classlists at build-time
> bug: https://bugs.openjdk.java.net/browse/JDK-8150044
> webrevs:
> top: http://cr.openjdk.java.net/~redestad/8150044/top.01/
> jdk: http://cr.openjdk.java.net/~redestad/8150044/jdk.01/
> hotspot: http://cr.openjdk.java.net/~redestad/8150044/hotspot.01/
> The implementation generates an interim image consisting of a minimal
> set of modules, then use this to run a small generator program to
> load common utilities and facilities and dump the result of this to a
> classlist that is then bundled with the final images.
> The smaller number of classes on the default classlist (~1100 instead
> of ~2500) requires some adjustment to the metaspace defaults.
> This achieves the following:
> - Removes a manual, error-prone process to update the versioned
>   classlists
> - Ensures the classlists shipped with the JDK/JRE is up to date
>   with recent JDK changes, e.g., when moving classes from sun.* to
>   jdk.internal.*
> - Automatically picks up and incorporates the output of jlink plugins
>   such as GenerateJLIClassesPlugin into the classlist
> - Supports cross-compilation build targets, although it runs using a
>   build JDK that can run on the host platform to generate such
>   classlists (this isn't ideal, but no worse than the current
>   situation, where the versioned classlist for the host platform is
>   simply copied to the cross-compiled target)
> There are a few concerns/drawbacks:
> - It does add complexity to the build, and concern has been voiced that
>   this would adversely affect build times. However, I'm happy to say
>   that on my machine build times are roughly the same:
> Before:
> real    2m37.303s
> user    35m33.576s
> sys    3m46.476s
> After:
> real    2m36.168s
> user    35m31.232s
> sys    3m52.268s
> (real time varies ± 5s from build to build)
> - Startup on the specific applications we've used to generate the
>   classlists for previously suffer small regressions. These are
>   specifically rather dated AWT and Swing-based applications. OTOH,
>   startup characteristics generally improve on other applications
>   (minimal VM, jetty, etc...)
> Testing: JPRT -testset hotspot
> Thanks!
> /Claes

More information about the build-dev mailing list