Right. What I'm trying to say, thought, is that if you can show a region can't shrink by GC, then there is no reason to run GC on it. So with care, it becomes possible to build programs in which we can witness that GC can't usefully be called.
On Tue, Jul 30, 2013 at 7:22 PM, David Jeske <[email protected]> wrote: > On Tue, Jul 30, 2013 at 6:38 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> Think about it again: all overwrites occur on borrowed pointers. If a >> reference resides in a borrowed pointer, then *by definition* the >> livelyness of its target object is guaranteed by some non-borrowed pointer >> somewhere else. >> > > I think I understand this part. For example, if we have an object pointer > at stack-frame-0, borrow an interior pointer to it on stack-frame-1, we can > then put that borrowed pointer into a stack structure on stack-frame-2 > because we're assured the object-pointer is alive two stack frames above > us. We can also put it into a region which is created on the stack above > frame-0, because we know this region will be destroyed before the > object-pointer is. > > Did I get that right so far? > > >> Since this is true, *there is no point collecting a region until a >> non-borrowed pointer has been overwritten*, because there are no dropped >> objects to be collected. >> > > Sure, I follow this too, but I don't see how this allows you to do > anything more than what I said above. (aka a strict stack discipline for > borrowed pointers from objects on parent stack frames) > > Or is that all you're saying you can do? > > I don't currently see the use of this. Our object pointer on frame-0 only > guarantees internal borrowed pointers on that object. Likewise for the root > of our leaf region. Any other object in either region could be collected, > unless we are part of another stack-discention. > > I see the value of stack disciplined borrowed pointers to objects, I guess > I just don't see how this buys you much when all the regions are running GC > on themselves. > > ... unless the region is basically one big object array which we know is > all referenced? > > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
