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

[Brian Goetz]

Anyway, in case it wasn't obvious, we're going to focus on the "one 
specialization per instantiation" approach for the time being.

On 8/18/2014 11:37 AM, Remi Forax 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
>