[PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
john.r.rose at oracle.com
Thu Nov 2 22:13:51 UTC 2017
On Nov 2, 2017, at 3:00 PM, Christoph Dreis <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.
More information about the core-libs-dev