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