hg: valhalla/valhalla/langtools: Add experimental support for generic class literals
brian.goetz at oracle.com
Mon Aug 18 16:08:31 UTC 2014
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
> 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 :(
>> 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