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

[Brian Goetz]

One note on this: Our VM calls this bitmap the "oopmap", where for each 
each class it staticall computes the reference-primitive footprint for 
instances.  Value types will require some (small) evolution to this, for 
collecting arrays of values.  Since values may have reference 
components, you need to overlay the component type oopmap over each 
element of a packed value array.  Not complicated but it is one thing to 
add to the to-do list.


On 1/5/2015 5:16 PM, Maurizio Cimadamore wrote:
>
> On 05/01/15 20:01, Gavin King wrote:
>> This is exactly the same as with an Any field: it may or may not
>> reference an instance, depending upon whether it is null or primitive.
> Exact GC algorithms assume you have a way of knowing where your
> references are. In JVMs (at least the ones I know) this is typically
> done by associating a GC bitmask where, for each field of a given class
> C, a 0 means primitive and 1 means reference; the GC will only 'follow'
> the fields whose bit is set to 1. Now, you have the problem of 'nulls'
> but, if you think about it, 'null' is a very very special value - it's a
> reference with all bits set to 0. So it is very easy for the GC to call
> that one out.
>
> Now think about a field whose type is Any - the mask should be set
> conservatively to 1, as _in principle_ this might hold a reference to
> another object, right? But then, how does the VM/GC distinguish between
> an instance of a value class (i.e. value) and a reference? I.e. how can
> the GC be instructed not to follow that particular 64-bit value that
> looks 'like' a reference?
>
> Now, I can think of several ways around this (and this is not the point
> of this email) - but let's not pretend that all this is straightforward.
>
> Maurizio