On Sun, Nov 24, 2013 at 4:03 AM, Ben Kloosterman <[email protected]> wrote:
> Right now there is no ref counting at all in RC-Immix if there is > sufficient space , if there is no collect ( or few collects ) than the > mod bufs could be an enormous chain . Also new objects may not be evacuated > ... > If we assume that we use the allocate-as-dead and lazy-modbuf-insertion optimizations described on p. 9 of the "Down for the Count?" paper, then the modbuf is *empty* prior to the first collection. We can even perform several *non-RC* collections during this phase, as long as surviving objects continue to be marked N,M (new, logged). At some point we decide to shift regimes, and the next major collection turns of the (N, M) bits as it proceeds. This in turn triggers coalesced reference counting that is performed by the mutator. 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. 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? > ...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? 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
