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 important, but it feels like this would be best addressed by not running such code interpreted at all — at runtime — but generating some blueprints at compile time which unpack into the objects using a VM wide shared hot loop.
Sent from Outlook On Mon, Nov 9, 2015 at 12:45 PM -0800, "Stuart Marks" <stuart.ma...@oracle.com> 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 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