On Mon, Nov 25, 2013 at 1:11 PM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > Yep > > >> 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. > > Yes im talking about doing some of this incrementally so if you can free the object between collections ( ie Nursery sweeps) its pretty cheap to see if the line is free ( unless you dont have stop the world nurseries) Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
