[PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
Claes Redestad
claes.redestad at oracle.com
Thu Nov 2 23:25:11 UTC 2017
On 2017-11-02 23:13, John Rose wrote:
> On Nov 2, 2017, at 3:00 PM, Christoph Dreis
> <christoph.dreis at freenet.de <mailto:christoph.dreis at freenet.de>> wrote:
>>
>> Thanks for the clarification. Actually the more important concern was
>> to get rid of unnecessary allocations that the cloning inside
>> Executable.getParameterTypes() is producing. As Claes mentioned
>> experience and experiments show that JIT's escaping mechanisms fail
>> from time to time on this one. And if you ask me it is not good
>> practice to rely on the compiler optimizations anyhow, but that's
>> maybe just me.
>>
>> I do like your proposal nonetheless as an additional improvement, but
>> I think it won't achieve the allocation-free part I was aiming for.
>> Correct me if I'm wrong, please.
>
> There are two ways it can directly achieve what you are after.
>
> First, if the guts of the jlr.Method can cache the List and return
> the same value every time. Then the legacy API point can use
> List::toArray to create the legacy array values.
>
> Second, if the guts of the jlr.Method choose to cache the Class[],
> it can still return a List wrapped around the same array, each time,
> as long as the List refuses modification.
>
> Either option avoids the O(N) copying and avoids problems
> with escape analysis. The second option has O(1) allocation,
> the first does zero allocation.
>
> The first option also allows constant propagation through the
> List.of values, something that arrays can never do (until we
> introduce frozen arrays). This bit of magic is one of several
> reasons people who program with arrays should try to move
> over to lists. It is enabled by the private annotation @Stable.
>
> — John
I like the first option, and it'd be a nice extra to allow consumers to
move forward from a 90s to an early 2000s programming model. :-)
One drawback is that this would be a somewhat larger effort to a
piece of sensitive, legacy code, but my gut feeling is that by moving
over from arrays to immutable Lists we are likely to reduce risk of
certain bugs creeping in.
/Claes
More information about the core-libs-dev
mailing list