RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin
Mandy Chung
mandy.chung at oracle.com
Fri Sep 6 19:07:08 UTC 2019
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
More information about the core-libs-dev
mailing list