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.in    Thu May 05 22:39:14 2016 
> -0700
> +++ b/common/autoconf/buildjdk-spec.gmk.in    Fri 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:
>> 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
>