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.
/Claes
