Re: RFR: 8150044: Generate classlists at build-time

[Erik Joelsson]

Looks good!

/Erik

On 2016-05-06 15:35, Claes Redestad wrote:

Hi,

an innocuous last minute change slipped in which actually broke 
cross-compilation support. Adding this puts things back in order:


diff -r c861a5be9c88 common/autoconf/buildjdk-spec.gmk.in
--- a/common/autoconf/buildjdk-spec.gmk.inThu May 05 22:39:14 2016 
-0700
+++ b/common/autoconf/buildjdk-spec.gmk.inFri May 06 14:47:12 2016 
+0200

@@ -46,6 +46,7 @@
 HOTSPOT_DIST := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(HOTSPOT_DIST))
 SUPPORT_OUTPUTDIR := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(SUPPORT_OUTPUTDIR))
 JDK_OUTPUTDIR := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(JDK_OUTPUTDIR))
+IMAGES_OUTPUTDIR := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(IMAGES_OUTPUTDIR))


 OPENJDK_BUILD_CPU_LEGACY := @OPENJDK_BUILD_CPU_LEGACY@
 OPENJDK_BUILD_CPU_LEGACY_LIB := @OPENJDK_BUILD_CPU_LEGACY_LIB@

Re-running and doing more extensive testing via RBT; arm64 builds have 
already completed so tentatively looks clear.


As there are follow-up work in jake lined up which depends on this we 
want to push this directly to jdk9/dev as soon as possible. I heard 
Alan already mentioned this and got no push back, so unless there are 
loud objections I'll go ahead and submit the jprt push job as soon as 
tests finish.


Thanks!

/Claes

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:
real2m37.303s
user35m33.576s
sys3m46.476s

After:
real2m36.168s
user35m31.232s
sys3m52.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

Re: RFR: 8150044: Generate classlists at build-time

[Claes Redestad]

Hi,

an innocuous last minute change slipped in which actually broke 
cross-compilation support. Adding this puts things back in order:


diff -r c861a5be9c88 common/autoconf/buildjdk-spec.gmk.in
--- a/common/autoconf/buildjdk-spec.gmk.inThu May 05 22:39:14 2016 -0700
+++ b/common/autoconf/buildjdk-spec.gmk.inFri May 06 14:47:12 2016 +0200
@@ -46,6 +46,7 @@
 HOTSPOT_DIST := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(HOTSPOT_DIST))
 SUPPORT_OUTPUTDIR := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(SUPPORT_OUTPUTDIR))
 JDK_OUTPUTDIR := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(JDK_OUTPUTDIR))
+IMAGES_OUTPUTDIR := $(patsubst 
$(BUILD_OUTPUT)%,$(BUILDJDK_OUTPUTDIR)%,$(IMAGES_OUTPUTDIR))


 OPENJDK_BUILD_CPU_LEGACY := @OPENJDK_BUILD_CPU_LEGACY@
 OPENJDK_BUILD_CPU_LEGACY_LIB := @OPENJDK_BUILD_CPU_LEGACY_LIB@

Re-running and doing more extensive testing via RBT; arm64 builds have 
already completed so tentatively looks clear.


As there are follow-up work in jake lined up which depends on this we 
want to push this directly to jdk9/dev as soon as possible. I heard Alan 
already mentioned this and got no push back, so unless there are loud 
objections I'll go ahead and submit the jprt push job as soon as tests 
finish.


Thanks!

/Claes

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:
real2m37.303s
user35m33.576s
sys3m46.476s

After:
real2m36.168s
user35m31.232s
sys3m52.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

Re: RFR: 8150044: Generate classlists at build-time

[Mandy Chung]

> On May 4, 2016, at 1:12 PM, Claes Redestad  wrote:
> 
> 
>> 
>> One question: where do you create the interim JMOD files?  Or do you create 
>> it under images/jmods?
> 
> No interim jmods are created for regular builds, while for cross-compilation 
> a buildjdk is created from JMOD files generated into buildjdk/images/jmods


I see. $(CREATING_BUILDJDK) indicates a cross-compilation build.

thanks
Mandy

Re: RFR: 8150044: Generate classlists at build-time

[Claes Redestad]

On 2016-05-04 21:45, Mandy Chung wrote:

On May 4, 2016, at 6:36 AM, 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.

This looks good and finally get rid of the prebaked classlists.


Thanks!



One question: where do you create the interim JMOD files?  Or do you create it 
under images/jmods?


No interim jmods are created for regular builds, while for 
cross-compilation a buildjdk is created from JMOD files generated into 
buildjdk/images/jmods


Thanks!

/Claes

Re: RFR: 8150044: Generate classlists at build-time

[Mandy Chung]

> On May 4, 2016, at 6:36 AM, 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.

This looks good and finally get rid of the prebaked classlists.

One question: where do you create the interim JMOD files?  Or do you create it 
under images/jmods?

Mandy

Re: RFR: 8150044: Generate classlists at build-time

[Claes Redestad]

Hi Ioi,

On 2016-05-04 16:05, Ioi Lam wrote:

Hi Claes,

The HotSpot changes look good to me.


thanks!



I am not knowledgeable enough to comment on the top repo makefile 
changes.


Regarding the JDK changes, in HelloClasslist.java:

Maybe add a comment about how/why you choose this particular set of 
operations? When the JDK evolves in the future, how should this file 
be changed?


I've done a few cycles of experiments to get something that shows a good 
improvement on our minimal and server-style startup test, while 
mitigating the regressions we'll inevitably see

on some of the GUI apps.

It'd definitely be interesting to iterate a bit on this as the JDK 
evolves, and I think one of the benefits of this solution is that such 
experiments are quite straightforward to setup.




I notice that no GUI classes are used. Is the reason (a) GUI classes 
are not important anymore, or (b) the build would fail in a headless 
environment if GUI classes were used by HelloClasslist.java?


A bit of both:

(b) Yes, requiring build environments to have a graphical environment is 
complicated, but not impossible. We'd prefer not to have add that 
requirement.


(a) Yes and no... while GUI classes aren't unimportant in and off 
themselves, jigsaw, java.lang.invoke and other features are adding to 
the number of java classes needed to bootstrap Java, and thus we'd see 
the CDS archive grow ever larger if we simply kept refreshing the 
classlists using the same technique as before. This actually has other 
drawbacks such as reducing the chance the CDS archive will be 
successfully mapped, especially on 32-bit platforms with ASLR. For 
example on Windows 32-bit startup tests, the regression on GUI apps is 
mostly offset by having a higher success rate.


Thanks!

/Claes



Thanks
- Ioi


On 5/4/16 6:36 AM, 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:
real2m37.303s
user35m33.576s
sys3m46.476s

After:
real2m36.168s
user35m31.232s
sys3m52.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

Re: RFR: 8150044: Generate classlists at build-time

[Jim Laskey (Oracle)]

Once installed, autoconf ran properly with make reconfigure - thx.


> On May 4, 2016, at 11:24 AM, Erik Joelsson  wrote:
> 
> Depends on which OS you are using. You need version 2.69, which is the 
> latest. On linux, "apt-get/yum install autoconf" should do the trick unless 
> your distribution is ancient. On windows add autoconf through the cygwin 
> installer. On mac I think "brew install autoconf" is easiest if you are into 
> that. If all else fails, downloading the source [1] and building is pretty 
> easy and straightforward too.
> 
> /Erik
> 
> [1] http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
> 
> On 2016-05-04 16:13, Jim Laskey (Oracle) wrote:
>> Correct.  How do I set up autogen so I can apply these changes?
>> 
>> 
>>> On May 4, 2016, at 11:11 AM, Erik Joelsson  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:
 real2m37.303s
 user35m33.576s
 sys3m46.476s
 
 After:
 real2m36.168s
 user35m31.232s
 sys3m52.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
> 

Re: RFR: 8150044: Generate classlists at build-time

[Alan Bateman]

On 04/05/2016 15:05, Ioi Lam wrote:

:

Regarding the JDK changes, in HelloClasslist.java:

Maybe add a comment about how/why you choose this particular set of 
operations? When the JDK evolves in the future, how should this file 
be changed?


I notice that no GUI classes are used. Is the reason (a) GUI classes 
are not important anymore, or (b) the build would fail in a headless 
environment if GUI classes were used by HelloClasslist.java?
Good questions on what to put into HelloClasslist. For now, I think what 
Claes has is good. The important thing is that it captures the classes 
that are loaded during startup, esp with the module system being 
initialized as part of VM startup, also anything using lambda or streams 
means a lot of classes are loaded. So I think it's a good start and I 
doubt we want to put too much into it as otherwise the #classes will be 
huge and we will be back to a huge archive again.


Hard to know what to say about UI applications and getting something 
that is representative of modern applications. There is nothing stopping 
anyone creating their own classlist of course.


-Alan.

Re: RFR: 8150044: Generate classlists at build-time

[Erik Joelsson]

Depends on which OS you are using. You need version 2.69, which is the 
latest. On linux, "apt-get/yum install autoconf" should do the trick 
unless your distribution is ancient. On windows add autoconf through the 
cygwin installer. On mac I think "brew install autoconf" is easiest if 
you are into that. If all else fails, downloading the source [1] and 
building is pretty easy and straightforward too.


/Erik

[1] http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz

On 2016-05-04 16:13, Jim Laskey (Oracle) wrote:

Correct.  How do I set up autogen so I can apply these changes?



On May 4, 2016, at 11:11 AM, Erik Joelsson  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:
real2m37.303s
user35m33.576s
sys3m46.476s

After:
real2m36.168s
user35m31.232s
sys3m52.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

Re: RFR: 8150044: Generate classlists at build-time

[Jim Laskey (Oracle)]

Correct.  How do I set up autogen so I can apply these changes?


> On May 4, 2016, at 11:11 AM, Erik Joelsson  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:
>> real2m37.303s
>> user35m33.576s
>> sys3m46.476s
>> 
>> After:
>> real2m36.168s
>> user35m31.232s
>> sys3m52.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
> 

Re: RFR: 8150044: Generate classlists at build-time

[Erik Joelsson]

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:
real2m37.303s
user35m33.576s
sys3m46.476s

After:
real2m36.168s
user35m31.232s
sys3m52.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