On Sun, Nov 24, 2013 at 8:52 PM, Ben Kloosterman <[email protected]> wrote:
> 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) . > Ah. So you are saying that if the object is write-hot it will end up getting put in *somebody's* modbuf almost all the time, and this will occur at approximately the rate of nursery collections if the modbuf lives in the nursery. Yes. I can see how that might happen. Really need some trace data to understand how often this happens, though. > 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. > But you don't *know* a line is empty until somebody processes the containing block - which is what the major collection does (or possibly a generational collection). This part can be done very incrementally, though. > 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 .. > Yup. Though it's useful to know which things take us over that cliff and which are easily done within the current conceptual framework. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
