On Dec 2, 2014, at 10:15 AM, Mark S. Miller wrote:

> Good. I think we're coming to a mutual understanding. By "scavenge" I
> mean exactly your "minor collection". I think collecting typical
> garbage during minor collection, rather than promoting/tenuring it, is
> desperately important, and dominates the other efficiency
> considerations mentioned in this thread. Of the common scenario, you
> say:
> 
>> In a minor collection nothing is collected, because it doesn't handle
>> ephemerons at all.
> 
> which clears up my confusion from your earlier claim

The very first implementation of Ephemerons we did at Digitalk was in the 
context of a multi-generationational  ( my recollection was that it had 5 
generations) scavenging collector and it did processes ephemerons at every 
generational level of scavenging. And quite efficiently using various 
remembered set tricks and other heuristics to deal with cross-generational 
references from ephemerons.  

I've always felt that the essentially two generation model that Ungar 
introduced (new/old space, minor/major collection, etc.) was too simplistic.  
It really has only two modes fast and slow (or incremental).  Multiple 
generations are better at dealing with the wider distribution of object life 
times that occur in a typical application.  I'm not convinced that only 
processing ephemerons during a "major collection" is a good heuristic .


> 
>> the value in a (map,key,value) triple can be reclaimed _immediately_
>> (in the same cycle) when _either_ the map _or_ the key dies.
> 
> In the common scenario, as of the moment of the minor collection, the
> key and value are unreachable, but v8 collects neither. Instead, both
> are expensively promoted/tenured.
> 
> Of the transposed scenario, you say:
> 
>> In both minor or major collection both m and v are immediately
>> reclaimed, because neither is strongly reachable at that point
> 
> which shows the asymmetry, and that v8 is effectively optimizing for
> the wrong side of that asymmetry. By adopting what Allen and I refer
> to as the transposed representation (as opposed to your transposed
> representation), you'd instead be able to say of the common scenario
> 
>> In both minor or major collection both k and v are immediately
>> reclaimed, because neither is strongly reachable at that point
> 
> which would be much more valuable than any other efficiency issue
> discussed in this thread.
> 
> In any case, we now both understand that you can't have both at the
> moment of a minor collection because, as we agree, a minor collection
> 
>> doesn't handle ephemerons at all.
> 
> You have to choose one side or the other. Why optimize for the
> transposed scenario rather than the common one?
> 

My main take-away from this discussion is that not have a 'clear' method on 
WeakMap/Set is indeed a simpler semantics and hence leaves GC designers more 
optimization opportunities.  

Allen


_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to