On Thu, Mar 5, 2009 at 10:50 AM, Jonathan S. Shapiro <[email protected]> wrote:
> On Thu, Mar 5, 2009 at 1:39 PM, Mark Miller <[email protected]> wrote:
>> Even among vats on different machines communicating over CapTP, we do
>> distributed acyclic GC.
>
> I do not understand how this is possible when VATs become unreachable.
> It's a well known problem in distributed GC generally, and the usual
> solution (at some level) is to reify the distribution boundaries --
> which seems to be what VATs do.
E distinguishes between remote live references, which get permanently
severed by partition, and sturdy references, which don't. If Vat A
becomes unreachable from Vat B, all live references from B to A break,
so any objects A hosts which are reachable only from live references
held by B may now be safely collected.
Sturdy references are only reclaimed when their lease expires. Modulo
some details, this is conventional.
> But I need to stop debating this. You certainly know your system far
> better than I do. The only question I want to raise right now is: is
> there something here that is relevant and focal in the context of the
> current discussion? I do not mean to imply that there is not. I am
> asking because I am not clear whether there may be.
You could distinguish between near references, which can only be used
within a region but are reliable, vs far references, which work across
regions until the region they point into has been terminated, vs data
which work both within and between regions reliably. For BitC, imagine
that far references could only designate remotely invokable closures,
where a remotely invokable closures is one whose parameters and return
results were limited to remotely invokable closures, far references,
and data. Implementationally, a far reference could be tuple of
* a pointer to such a closure
* an allocation count location for the region containing that closure
* the allocation count to check against that location.
Your collector could then know not to trace the pointer-to-closure if
the allocation counts disagree.
Any inter-region call might fail, and so should the call expression
should have a type that acknowledges that possibility. If inter-region
invocation is necessarily asynchronous, that's the end of the story.
If you allow inter-region synchronous calls, then you need to worry
about region termination invalidating *some* of the frames of the call
stack.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
