> > > The only point here is that you can not only imagine a heap using mixed > regimes in different places (RC vs. collection), you can also imagine a > regime shift that occurs between program startup and program steady state. > Given that you need the background collector for cycle detection anyway, it > doesn't feel like it ought to be that much marginal effort. > > Whether it's worthwhile is a matter for measurement. >
I think it will be even for non copying but yes we can measure it. > > eg 1. There is a complication when we introduce a ( locally allocated >> shared) Nursery... >> > > Confused. How can a nursery be both locally allocated and shared? > By sharing a fixed block pool that is swept / cleared in unison. 1 thread may dominate but that is fine as long as the pool is proportional to the number of threads. > > >> ...while we can use the modbuf to track changes ( its the write barrier ) >> we need to process it when we sweep the nursery... >> > > Yes. In fact, I'm inclined to think that the modbuf should actually be > *allocated* from the nursery, since the lifespans are connected. > > We need a way so we dont look at the whole modbuf ( it could be massive ). >> > > I'm not sure why the modbuf should be massive, given the > lazy-modbuf-insertion optimization. The modbuf only gets into play when a > mature object that has already survived a collection is modified *again*. > What you suggest could certainly be right, but do we have any data? > No data next phase is to collect it but a mature object frequently changing objects eg a mode object would not be uncommon ( though much less so when you have value types) . > > eg 2, Im not sure if there are any holes ( free lines) created by >> processing a modbuff/newbuff and ref counts going to 0 outside of the stop >> the world collect phase. I dont think so and it is desirable as holes open >> up without a collect. >> > > I think there should be. Processing the modbuf and ZCT will cause some > object reference counts to go to zero. That in turn causes the > objects-in-line count to decrement. The objects-in-line decrement can be > done eagerly or lazily. My sense is that it should be done lazily, because > we're not really interested in free lines until we reconsider the block as > a candidate for recycling, and we have to make a pass then in any case. > > I think it should be lazy as well but not not wait till a full collection , once a line is empty the object can be marked for recycling. Note the keypoint here is the moment we detach from doing everything during the Collection than we really have a new collector and we have to redesign lots of behaviour .. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
