hg: valhalla/valhalla/langtools: Add experimental support for generic class literals

[David Chase]

Regarding code-sharing and specialization, even when it’s possible, it’s not necessarily what you want,
and it seems to take HotSpot and Graal some time to figure out the right amount of inlining.

I’ve been playing with a numerically oriented prototype for the matrix and and arrays part of Arrays2.0,
and one thing that has become clear is that when everything is monomorphic wonderful things happen,
and that as soon as N > 1, wonderful things take much longer to happen, if ever, and “not wonderful”
can be a 10x performance hit.

I’m still working the “how do I help the optimizer” angle and I don’t think I’m done with that, but I there’s
a place where it would be really helpful (from the POV of predictable high performance) if I were able
to say “right here, specialize this, and propagate some code constants please”.

On 2014-08-18, at 11:37 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> On 08/18/2014 05:25 PM, Brian Goetz wrote:
>> The code-sharing possibilities between a byte version and an int version of List are obvious; there are tradeoffs to be made between code footprint and data footprint that have no obvious one-size-fits-all answer.
>> 
>> It gets nastier when you start to consider arbitrary value types, because values can hold references and references are special.  So the obvious approach of specializing one set of native code for 64-bit values, another for 96-bit values, etc, runs the risk of leaking references as ordinary bits.  One use a code-sharing model that treats all the non-reference bits in one bucket and all the reference bits in another, like "n longs and m references", but this starts to get complicated.
> 
> Technically, because of alignment, it make sense to group value types using 64 bits bucket (64, 128, etc).
> About reference vs primtives, in an ideal world, the problem is how you tell the GC which field is a reference and which stack slot/register is a reference,
> so you can share the same code and have different GC metadata for each value type of the same size.
> In the real world, you have to fight with the actual representation used by Hotspot :(
> 
> cheers,
> Rémi
> 
>> 
>> 
>> 
>> On 8/18/2014 11:02 AM, Maurizio Cimadamore wrote:
>>> 
>>> On 18/08/14 15:48, Remi Forax wrote:
>>>> So the real number of variation is not clear yet (at least for me) but
>>>> each time you use 'any', you request for more specializations.
>>> Well, as soon as you start considering value types, the number of
>>> specialized classes is virtually unbound, regadless of what we do for
>>> byte/char/short, as we need a specialized Box<T> for each value class T.
>>> 
>>> Maurizio
>