[11] RFR 8195694: ConstantBootstraps.invoke does not preserve variable arity
John Rose
john.r.rose at oracle.com
Thu Feb 1 12:26:59 UTC 2018
On Feb 1, 2018, at 12:45 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>
>
>> On Jan 31, 2018, at 3:49 PM, John Rose <john.r.rose at oracle.com> wrote:
>>
>> On second thought, you should also use invokeWithArguments to support jumbo arities.
>>
>
> It does, but non-selectively based on the arity:
>
> 245 return handle.invokeWithArguments(args);
>
>
>> This tricky idiom should be put into a utility method, package private for starters. A version of it also appears in BSM invocation code.
>>
>
> Are you in part referring to the approach of switching on the number of arguments and using invoke with unpacking for small cases?
That might be worth doing as an internal optimization in a reusable library function. But my main concern is correctness: packaging a tricky idiom instead of having users re-derive it by noticing bugs in the near-miss approximations.
We put in withVarargs to capture some of the idiom, but we aren’t there yet. The big you are fixing had happened in several places and the root cause is the lack of an advertised best practice. Hence my interest in a utility method, eventually a public one.
>
> If you don’t object i would like to follow up on that with another issue.
Sure.
>
>
>>> On Jan 31, 2018, at 3:23 PM, John Rose <john.r.rose at oracle.com> wrote:
>>>
>>> If you remove the old asType call it’s good!
>>>
>
>
> Ah! something went wrong when importing the patch from the amber repo. Updated in place.
>
> Paul.
>
>>>> On Jan 31, 2018, at 3:15 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review this fix to the invoke BSM so that it preserves variable arity, if any:
>>>>
>>>> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195694-constant-bsms-invoke-arity/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195694-constant-bsms-invoke-arity/webrev/>
>>>>
>>>> This will be pushed to the hs repo.
>>>>
>>>> Thanks,
>>>> Paul.
>>>
>>
>
More information about the core-libs-dev
mailing list