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 ... [email protected]
