On 31 October 2013 12:26, Ben Kloosterman <[email protected]> wrote:
> Here you can map the data onto C but you have variable sized object header..
>
> Obj Header
> Field1
> Internal Header 1..
> Value type  1
> Internal Header 2..
> Value type  2
> Field 3
>
> Here you cant map the whole object onto a C object  ( or say a network
> packet header) as the C object doesnt have the header so you need fancy
> marshalling avoiding it is one of the main drivers for embedded nonboxed
> arrays .

References to C value types are not garbage collected, at least, not
directly; so there is no problem here.

The problem is with references to types that are usually garbage
collected.  Even if the language can guarantee that a pointer to the
containing object is live, we need to

0. Know that the reference is an interior pointer, so that we can
handle the case that the object is forwarded from the mutator.  The
thing is, as the one holding a reference, you probably don't want to
have to care while using the object.  This is specifically a problem
when the mutator can be running during semispace collection.

1. Know how to determine the containing object from the interior
pointer.  The real issue is that you want to copy the containing
object, and then you want to know how to forward your reference.

The point is that this can be done with a per-object header for values
managed by the runtime, which need to track where the containing
object is (which we can then check to see if our reference should be
forwarded).  It doesn't impact the behaviour of structs on the C side.


Discussions of barriers and GC I'm still meditating on.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely may reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to deny you those rights would be illegal without
prior contractual agreement.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to