Correct. How do I set up autogen so I can apply these changes?
> On May 4, 2016, at 11:11 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > 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. > > /Erik > > 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 >
