Hi Claes, The patch looks much straightforward than I expected.
The original default hardcoded list includes many more forms. What is the diff of the jlink-plugin generated classes before and after this patch?
I wonder if we should include a few other method types in HelloClassList like float parameter. While they are not used in the startup benchmarks, they may be used for some other application runtime which has been benefit from jlink-time generated classes.
Mandy On 9/2/19 7:02 AM, Claes Redestad wrote:
Hi, we should avoid hard-coding the set of dynamically generated j.l.invoke classes to pre-generate into the jlink plugin, instead favoring generating the set of code to use at build-time. Webrev: http://cr.openjdk.java.net/~redestad/8230301/webrev.00/ Several of the hard-coded defaults predate optimizations to remove MH usage in lambda bootstrap and were generated using earlier iterations of ISC. This means many classes/methods generated are actualy never used, and that dropping all the defaults had relatively minimal effect on our set of startup tests. It's easy to create increasingly synthetic applications that suffer marginally. I did some experiments and identified a few small API calls we can add to HelloClasslist to recuperate a fair amount on some key applications, while still significantly reducing size of pre-generated code. Testing: tier1-3 Thanks! /Claes
