[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.


More information about the core-libs-dev mailing list