hg: valhalla/valhalla/langtools: Add experimental support for generic class literals
forax at univ-mlv.fr
Mon Aug 18 15:37:26 UTC 2014
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
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
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 :(
> 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.
More information about the valhalla-dev