Fwd: Fwd: Proposal for generics over primitives needs a rethink

Remi Forax forax at univ-mlv.fr
Sat Jan 3 16:10:15 UTC 2015

On 01/02/2015 07:13 PM, Gavin King wrote:

> So, can we just drop this whole subthread, do a full reset here, and
> get back to the much more interesting technical issues, *please*?
> Because I think this is potentially a really great opportunity to make
> Java better, and I want to be convinced it's being done the Right Way.

so full reset.

The Any problems.

The first major problem of Any is that it introduce a new primitive kind,
a lot of codes relies on the fact that you can only have boolean, byte, 
char, int, long, double and Object in Java. Introducing a new type will
make a lot of code to behave weirdly.

The second major problem is how to implement it.
It can be implemented as a compiler fiction only like in C# or in Scala,
but in that case apart that one can write ArrayList<int>, it will
rely on a form of boxing.
It can be implemented in the VM. It seems to be the best solution
but the engineering cost is insane and in fact Any will not solve
the specialization problem.

Why the engineering cost is very high ?
Currently most of the Java VM implementations rely on the fact that
you know upfront (without executing the code) if a field or a local variable
is a reference or an object. In term of GC, there is a very clear 
between the precise GC algorithms used in Java VM and the conservative
GC algorithms used by example in C. Technically, with Any, you can
implement something in the middle between these two categories of GC,
nevertheless, it changes the category of GCs, Java will be able to use.

Any will not solve the specialization problem.
Let say we now we have introduce Any, so we can create an array of Any.
But an array of Any can be at runtime by subtyping either
an array of doubles or an array of objects.
But by doing this we introduce a subtyping relationship between things that
are not structurally equivalent. A possible solution is to align all 
cells of all arrays
to 64 bits which is a very bad property because even if you don't use Any,
you pay the cost of that you may use it. Another solution, the one used 
by V8,
is to box all doubles (and long in Java) when you store them in an array*.
So an array of Any will not be magically an array of ints, an array of 
and an array of objects without some trade-offs.

The specialization as defined in the 'State of Specialization'
seems in my opinion a good way to go forward.


* that's why JavaScript defined a bunch of typed arrays

More information about the valhalla-dev mailing list