[code-reflection] RFR: Invocation to vararg methods

Paul Sandoz psandoz at openjdk.org
Tue Sep 10 15:23:16 UTC 2024


On Tue, 10 Sep 2024 14:57:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
>> 
>> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
>> 
>> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).
>
> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 1519:
> 
>> 1517:             HashMap<String, Object> m = new HashMap<>(super.attributes());
>> 1518:             m.put("", invokeDescriptor);
>> 1519:             if (isVarArgs) {
> 
> This seems a bit of an arbitrary cut - e.g. we only generate as few attributes as possible, given we know how to infer some of those. I understand why: we don't want invoke ops to look to scary in the string representation...
> 
> Why do we need to emit the invokekind for variadic calls?

We don't need to in all cases - only required for super invocations. I just chose a path of least resistance when hacking it together. My main motivation was to avoid updating all the tests! Varargs calls are less common so I was not overly concerned about the scary strings.

But, for consistency I think it is worth addressing this. If `invoke.varargs` is present and `invoke.kind` is not we can infer static or instance invocation.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752189695


More information about the babylon-dev mailing list