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