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

[Vladimir Ivanov]

Reviewed.

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