RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin

Claes Redestad claes.redestad at oracle.com
Sat Sep 7 01:29:23 UTC 2019


Hi Mandy,

On 2019-09-06 21:07, Mandy Chung wrote:
> Hi Claes,
> 
> The patch looks much straightforward than I expected.

thanks? :-)

> 
> 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.
Yes, there's a reduction of forms pre-generated by this, but that's sort
of the point since the list of defaults was picked by me during JDK 9
development to fit the needs of the lambda metafactory the ISC we had
back then. Since both have been refactored over the last 4 feature
releases, many of the shapes herein now can never be requested by the
current ISC implementation, and are likely dead weight.

So I think of this cleanup as reclaiming some footprint that we can
spend on widening the API coverage in HelloClasslist to include things
that are more likely to be used by a large set of applications.

I do think there's a small risk this cleanup removes a handful of oft-
used shapes, but I'm not sure if it'll ever register as a measurable
regression. It's possible, sure, so I'd prefer to do an exploratory
tuning round to patch this up as a follow-up RFE, and have that effort
be guided by any regressions we (or others) may be able to detect due
this cleanup.

Thanks!

/Claes


More information about the core-libs-dev mailing list