RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin

[Mandy Chung]

On 9/6/19 6:29 PM, Claes Redestad wrote:
>>
>> 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.

I'm okay with this patch.

It'd be help to add a comment in the plugin what criteria to determine 
the shapes be pre-generated and give examples how to extend the 
pre-generated list in the future.

Mandy