Primitives in Generics

[Nathan Bryant]

Doug Lea wrote:

> For one example of a generics system that accommodates both A and B
> see the X10 specs:
> http://dist.codehaus.org/x10/documentation/languagespec/x10-latest.pdf
> Scala also comes close with upcoming "specialize" directives. See
>
http://www.scala-lang.org/sites/default/files/sids/dragos/Mon,%202009-11
-16,%2017:34/sid-spec.pdf
> or maybe some more recent docs?
> (Also, to some extent, C#.)

They come close, yet they're so far. If you've tried using @specalized
for anything serious in Scala, you'll start to see what I mean: scalac
starts generating incorrect bytecode for nontrivial cases. (As of
whatever release candidate or nightly build I most recently checked,
which was a month or two ago.) But even if they fix that... based on
what I could dig up, it sounds like part of the problem is that it
doesn't really preserve transitivity for @specialized, so it seems
likely that if the code generation issues are fixed, it is likely to
remain problematic in other respects.

So for the near term, it'll be great if the JVM *cough* MLVM
MethodHandle inlining is good enough to (a) transport closures to
another thread, (b) inline them there in a way that exposes autoboxing
elimination transformations, and (c) do all this in the presence of
megamorphic call sites, but I'm not holding my breath. All this stuff
seems novel.

> I worry a bit because (1) the base generic type systems for
> both are fairly different than Javas and (2) both implementations
> are still in pre-release mode running on JVMs.

Hmm, I'm not sure what you mean by this. Scala's type system seems like
a straightforward mapping on top of Java generics. If an Int parameter
is being used polymorphically as a subclass of Any, which should also be
the case for the generic erasure, it's going to be boxed to
java.lang.Integer.

Scala's type system does seem to map better to the CLR than to the JVM,
and that may turn out to be an advantage in the distant future.

Random thought about inlining heuristics: it seems like the JVM
shouldn't just consider the size of the method to be inlined. There
could be an advantage in considering the size of the method containing
the call site! And, perhaps, whether or not boxed primitives are present
in the signature.

Nathan

> -Doug