RFR: updated draft API for JEP 269 Convenience Collection Factories

[Peter Levart]

Hi Stuart,

I think that what matters are the methods that execute in tight loops. 
Some thousand array clones that would be performed while interpreting 
would be barely noticeable. I agree that JMH benchmarks presented here 
are not a representative for real-world tight loops. Especially because 
successful EA is very sensitive to various arrangements. But this can 
also be viewed as an opportunity to tune the JIT exactly for the 
situations that arise with such vararg collection factories. We would 
get a two-fold improvement: smaller API footprint and better 
optimization of non-escaping vararg arrays that might benefit other code 
too. OTOH I understand that this would be a larger undertaking involving 
more resources.

Regards, Peter


On 11/09/2015 09:44 PM, Stuart Marks wrote:
> Hi Michael, Peter,
>
> I admit to not having followed all the benchmarking discussion 
> (travel, Devoxx) but I did want to respond to this:
>
> Peter wrote:
>> So it looks like that there's no need to burden the public API with 
>> explicit argument overloads.
>
> These are JMH benchmarks, which take care to warm up the JIT, so that 
> everything is nicely optimized, inlined, escape-analyzed, etc., right?
>
> If so, I don't see this at all being representative of how these APIs 
> will be used. They won't be called in tight loops that give the JVM a 
> chance to optimize them. Instead, they'll be used for initializing 
> fields, including static fields:
>
>     class MyClass {
>         static final Set<String> set = Set.of("a", "b", "c");
>         ...
>     }
>
> This call to Set.of() will (probably) be called exactly once when 
> MyClass is loaded. It'll probably be run in interpretive mode. If the 
> API becomes popular, there will be lots of calls like this in static 
> initializers and instance initializers. Most of these will be called 
> once or relatively few times, but there may be a lot of such calls. I 
> think most of these would be run by the interpreter.
>
> How do we assess the impact of fixed-args vs varargs overloads for 
> cases like this?
>
> s'marks
>