Project Lambda: Java Language Specification draft

[Reinier Zwitserloot]

You're worried about the performance impact of 1 object allocation that is
almost guaranteed to be short-lived and may even be entirely eliminated by
the hotspot compiler?

Basing language decisions on that kind of backward thinking is a very very
bad idea.


Your argument also makes literally no sense at all, you should read your own
tripe before you post it. You're complaining about the performance of
*GENERATED* code such as parsers. WTF?

If for some reason the current paradigm of creating a new empty array list
and adding elements to it one element at a time is measurably faster than
using a hypothetical list literal, then, generate that code instead of the
list literal. Duh. It's a code generator. It's the one place where verbiage
and spectacular lack of brevity are utterly irrelevant.

I thought basing language decisions on fear of performance impact for a
short-lived singular object instantiation was as worse as it was going to
get, but you've outdone yourself in the span of a single post: You're now
basing decisions of language design on making life easy for code generators.
You've missed April 1st by a few months, mate.

--Reinier Zwitserloot



On Sun, Jan 24, 2010 at 10:53 PM, Osvaldo Pinali Doederlein <
opinali at gmail.com> wrote:

> Em 24/01/2010 18:59, Mark Thornton escreveu:
> > Osvaldo Pinali Doederlein wrote:
> >>
> >> The collection literals proposal is already underwhelming IMHO,
> >> because it boils down to sugar over the Collections.unmodifiableXxx()
> >> APIs. We
> > I partly agree. For lists and sets something like this
> >
> > public CollectionLiterals {
> > <T> public static List<T> list(T... e) {...}
> > }
> >
> > used with static import is almost as brief. Maps though are more
> > annoying to initialise. The best I can manage with existing Java
>
> These idioms (like Builder / fluent interfaces) are stuff I won't touch
> with a 10-foot pole. You are forced to allocate at least one extra
> object (a Builder), so there's extra overhead unless you rely on
> optimizations like escape analysis + scalar replacement. I don't like
> the language/library design of "let's ignore performance, make a mess,
> and pray our advanced JIT compiler will clean it up". This often fails,
> remarkably for client-side code that must run on the less featured VMs
> like HotSpot Client; startup/warmup time is another issue even for the
> top JITs. On top of that, even a good fluent interface is pathetic wrt
> readability if compared to proper language-level syntax. I prefer to
> completely ignore this technique/trend and just write a full page of
> add() or put() calls. </rant - don't take it personally>
>
> Tuples could be even worse, because now we're allocating one temp object
> per entry; now your runtime performance will certainly suffer miserably
> if these tuples are not optimized out (granted, that's more likely if
> tuples are added as "lightweight" headerless objects, which is something
> MLVM people are researching).
>
> It can be argued that the performance of literal collections is not very
> important because such collections are typically very small - people
> don't populate a million-element Map with literal code, right? This is a
> good general assumption, but there are important exceptions like
> machine-generated code (e.g. parsers) which often contains enormous
> datasets encoded as initialized variables. This remembers me of another
> RFE that I never lose an opportunity to remember: the classfile format's
> poor constant pool - you cannot encode a populated array, or an object
> that allows compile-time construction (e.g. "new Point(0,0)" -
> constructor only assigns to fields and is called with compile-time
> literals). Such initializations are supported by VERY bulky bytecode,
> that's initialized at class-init time or construction time, when ideally
> they could just be memcpy'd from the constant pool (or even mmapped,
> with something like the CDS).
>
> A+
> Osvaldo
>
> >
> > public CollectionLiterals {
> > public static <K,V> MapBuilder<K,V> mapOf(K key, V value) {...}
> > }
> >
> > public static interface MapBuilder<K, V> {
> >        MapBuilder<K,V> and(K key, V value);
> >        Map<K,V> create();
> > }
> >
> > Giving
> >
> > mapOf(a,b).and(c,d) ... .create();
> >
> > However I have managed a StackOverflow in javac with code like this :-(.
> >
> > Now if there was a short way of creating tuples so that
> >
> > public static <K,V> Map<K,V> mapOf(Map.Entry<K,V> ... entries) {}
> >
> > could be used like
> >
> > mapOf((a,b), (c,d), ...)
> >
> > preferably without so many parentheses.
> >
> >
> >> concrete implementations for these collections. While higher-level
> >> langs may contain multiple implementations of some collection and
> >> automatically pick or change the optimal impl for each situation (even
> > Easier to do with functional style where changing the implementation,
> > when a value or mapping is added or removed, presents no problem.
> >
> >
> > Mark
> >
>
>
>