RFR: 8163371: Enable tracing which JLI classes can be pre-generated

[Claes Redestad]

On 2016-08-26 15:40, Vladimir Ivanov wrote:
> Reviewed.

Thanks for reviewing!

/Claes

>
> Best regards,
> Vladimir Ivanov
>
> On 8/26/16 4:26 PM, Claes Redestad wrote:
>> Hi,
>>
>> please review this change which adds a means to trace what
>> LFs and BMH classes we try to resolve at runtime (and whether
>> we failed or succeeded), along with an update to the
>> --generate-jli-classes plugin to take as it's input a file containing
>> the output of such tracing.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163371
>> Webrev: http://cr.openjdk.java.net/~redestad/8163371/webrev.01/
>>
>> I picked a random use case to test/verify the implementation in
>> a minimal nashorn script, bin/jjs exit.js[1].
>>
>> 1. On my local JDK image this loads 2359 classes.
>> 2. On a jlink image with --generate-jli-classes=@empty to
>> disable the default pre-generation, 2450 classes are loaded
>> 3. On a jlink image built with the output of a tracing run[2],
>> 2114 classes are loaded
>>
>> Also, inspecting the output shows that a total of 42
>> BoundMethodHandle$Species_* classes were pregenerated in case
>> number 3, compared to 37 in the default case and 0 on the image
>> with no pregeneration, meaning we avoid generating a total of 378
>> classes at runtime.
>>
>> As a follow up I plan to add tests and explore the benefits of
>> adding a way to generate and use a relevant list of jli classes in the
>> build (adding to the existing CDS classlist generation mechanism
>> seems appropriate).
>>
>> Thanks!
>>
>> /Claes
>>
>> [1]
>> exit.js:
>> exit();
>>
>> [2]
>> bin/jjs -J-Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true exit.js >
>> trace.out
>> bin/jlink ... --generate-jli-classes=@trace.out