[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