On Nov 2, 2017, at 3:00 PM, Christoph Dreis <[email protected]> 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
