RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

Joseph D. Darcy joe.darcy at oracle.com
Wed Sep 29 01:01:03 UTC 2021

On 9/22/2021 4:53 PM, Claes Redestad wrote:
> On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов <github.com+10835776+stsypanov at openjdk.org> wrote:
>> Currently the method is implemented like
>> public List<Class<?>> parameterList() {
>>    return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
>> }
>> This seems to be excessive, as three objects are allocated here. Instead we can use `List.of(ptypes)` which doesn't allocate anything for empty array and for one of length 1 and 2 it allocates lightweight objects with 2 fields, still copying longer arrays. This is likely to be fruitful as most of methods have 0-2 parameters.
>> Also there is a couple of cases when `MethodType.parameterLis()` is called to get its size, which is excessive either as we can use `MethodType.parameterCount()` instead.
> I think it's OK and even expected to file a CSRs retroactively when you realize post integration that there's a behavior change. I recall doing so at least once in the past.

This scenario is discussed in the CSR FAQ:

> Q: Timing wise, when do I need to file a CSR request?
> A: A CSR request needs to be filed and approved /before/ the 
> corresponding change is pushed to a JDK release line of development. 
> In exceptional circumstances, the need for a CSR review may be 
> recognized only after a push has already occurred. In such cases, a 
> retroactive CSR review can be conducted. The results of such a 
> retroactive review may require updates to the change, up to and 
> including complete removal of the change.

For the change in question, are there any interactions with class file 
redefinition effects?


More information about the core-libs-dev mailing list