[PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
claes.redestad at oracle.com
Fri Nov 3 14:41:27 UTC 2017
On 2017-11-03 14:17, Alan Bateman wrote:
> On 03/11/2017 08:11, Christoph Dreis wrote:
>> Hi John,
>>>> this has a bigger impact on the overall footprint of
>>>> Method/Executable objects. What are your thoughts on this?
>>> The footprint is probably about the same. Small List.of values
>>> do not contain arrays, and may be smaller than arrays with the
>>> same number of elements, since they do not have a length field.
>>> And, indeed, methods typically have a small number of parameters.
>> Ah, so you would remove the current array field completely and
>> replace it with the immutable List, right?
>> In that case I said nothing. I was thinking of a field on top.
> The VM creates Method objects and sets the fields, including
> parameterTypes, directly so I think removing it would require more
> work than it initially looks. If you add a field then it does increase
> the footprint a bit. Alternatively, have the method could use a
> ImmutableCollection.ListN like implementation that is backed by the
> array and doesn't scan it for nulls at create time, this wouldn't be
> completely allocation free of course.
While it would be pretty sweet if we could train the VM to use List.of
as appropriate (might be applicable in a number of places where we want
to communicate immutable array-like data from the VM), it should be
pretty straightforward to change the interaction so that the VM calls a
private method that takes the parameter array and turns it into a List.
My guess is that the superfluous null checking will be hardly measurable
even in micros.
> In any case, the proposed API does look reasonable although it
> deviations from the usual conventions in java.lang.reflect.
I agree the getParameterType(index) method should still up for
consideration if we can't act on the more elegant proposal to turn
things into Lists in a reasonable time-frame.
More information about the core-libs-dev