Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

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

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi, My first thought would be that if we're running interpreted then we are already deep in the hole performance wise. If in addition we are class loading and initializing then our performance should be dominated by IO, a much deeper hole.  This isn't to say that class initializing cost isn't

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Stuart, I don't know if I have any new information to add. When I try to solve this equation, I: - Look at the difference between fixed-arg and non-optimized varargs from my benchmarks (allocating an array doesn't get faster with JIT optimizations, does it?), which is on the order of tens of

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

There's another issue with relying on EA, which is EA will not analyze methods above a certain (bytecode) size; IIRC it's around 150. So if this method gets inlined into a bulky method, the varargs will not be eliminated, I believe. I don't think it's a problem for this API for the reasons I

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

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

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Michael, You see, switch2 is on par with explicit for 0 and 1 args. switch10 probably suffers from to-many-bytecodes-per-method syndrome. I tried to shorten your switch2 and switch10 methods by delegating to explicit/varargs methods: @SafeVarargs static List varargs_switch2(E... ea)

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Peter, You're right. I see the same thing running that locally. Nice work! As a sanity check, I changed the code to mirror what I think it would look like in practice, and to make sure that structure didn't change any JIT optimizations. The code is attached. 1. use

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

I think the mailing list stripped my attachments, so I put it up on github: https://github.com/michaelhixson/jmh-benchmark-listof -Michael On Sun, Nov 8, 2015 at 2:55 PM, Michael Hixson wrote: > Hi Peter, > > You're right. I see the same thing running that locally.

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Michael, The comparison between explicit and varargs is not fair. Varargs is using arraycopy, which I think prevents vararg array allocation to be eliminated. Try to use a switch on varargs array length and then directly reference it's elements with constant indices for each case and construct

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

(Oops, forgot to cc the mailing list) Thanks for the explanations, Stuart. That all sounds reasonable and makes sense to me. I have some additional thoughts inline below, because this is interesting and I can't resist, but you could ignore them and not hurt any feelings. I also wrote up some

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

t;core-libs-dev@openjdk.java.net> > Envoyé: Vendredi 6 Novembre 2015 18:16:20 > Objet: Re: RFR: updated draft API for JEP 269 Convenience Collection Factories > > On 11/5/15 11:15 PM, Remi Forax wrote: > > Hi Stuart, > > reading the documentation, > > methods o

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

I haven't reviewed in detail, but it seems like the right set of methods. There may be a case for adding equivalent to Queue, Deque, NavigableSet and SortedSet, if not now maybe in the future, although their usage is markedly lower. Stephen On 6 November 2015 at 02:13, Stuart Marks

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

This is in reply to: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036331.html + static List of(E... es) { + for (E e : es) { + Objects.requireNonNull(e); + } + // NOTE: this can allow a null element to slip through + return

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Apps that are sensitive to allocations will not use these convenience methods in hot paths, varargs or fixed arg. They're likely to use them when the extra allocation wouldn't matter (non sensitive code, startup/initialization, etc). sent from my phone On Nov 6, 2015 1:29 PM, "Stuart Marks"

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

On 11/6/15 5:12 AM, Michael Hixson wrote: + static List of(E... es) { + for (E e : es) { + Objects.requireNonNull(e); + } + // NOTE: this can allow a null element to slip through + return Collections.unmodifiableList(Arrays.asList(es)); + }

RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi all, Sorry for the hiatus. I had this thing called JavaOne that I had to deal with Please review this updated draft API and implementation. Highlights of changes are: - factory methods removed from concrete collections - renamed Map.fromEntries() to Map.ofEntries() - increased

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

a.org/wiki/Factory_method_pattern - Mail original - > De: "Stuart Marks" <stuart.ma...@oracle.com> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Vendredi 6 Novembre 2015 03:13:12 > Objet: RFR: updated draft API for JEP 269 Co