RFC: draft API for JEP 269 Convenience Collection Factories
timo.kinnunen at gmail.com
Wed Oct 14 21:48:53 UTC 2015
No, I meant the number should be limited by how many arguments (not including the last varargs array) it is possible to pass in registers without having to spill any of them on the stack on some widely-used architecture like x86-64, for example. This lets clients on it use its full capabilities, doesn’t limit lower-end runtimes and provides a hint about a typical performance profile one could expect.
Sent from Mail for Windows 10
From: Rémi Forax
Sent: Wednesday, October 14, 2015 14:16
To: Timo Kinnunen;Paul Sandoz
Subject: RE: RFC: draft API for JEP 269 Convenience Collection Factories
You can have 255 parameters for a method, it's perhaps a little too much, isn't it ?
Le 14 octobre 2015 12:40:15 CEST, Timo Kinnunen <timo.kinnunen at gmail.com> a écrit :
>Alternatively you could create the variants whose parameters can be
>passed utilizing "all available registers", whatever that means in
>Java context. The rationale is that the reason for preferring variables
>over varargs is performance and this way there is no performance left
>on the table.
>Sent from Mail for Windows 10
>From: Paul Sandoz
>Sent: Wednesday, October 14, 2015 11:38
>Subject: Re: RFC: draft API for JEP 269 Convenience Collection
>> On 14 Oct 2015, at 06:18, Stuart Marks <stuart.marks at oracle.com>
>> I'm not entirely sure what to take from this. If it were clearly
>exponential, we could say with confidence that above a certain
>threshold there would be vanishingly little benefit adding more
>arguments. But since the curve seems to flatten out, maybe this is
>pushing us to add more pairs than we had originally thought. The
>current draft API has 8 pairs; that seems to leave a few percent of
>cases on the table. Obviously we can't get to 100%, but is 97% good
>11 if only for amusement purposes :-)
>Capturing 9 out of 10 cases seems reasonable to me i.e. 5 entries.
>Perhaps a common case for r > 5 entries is a map for the primitive
>types and ref (ignoring “void”), which would push the limit up to 9
>entries. I took a quick browse through the JDK and it is not that
>common AFAICT. j.l.invoke tends to use enums for example. There are two
>cases in java.ObjectInputStream and sun.misc.ProxyGenerator.
More information about the core-libs-dev