The weak reference harvester infrastructure is intended for use with inline caches and DFG optimized code that makes weak references to objects in the JavaScript heap. But there is a special car that requires special treatment: a put_by_id transition refers to two structures, previous and next, and has the semantics of installing the 'next' structure if the previous structure was 'previous'. Consider a sequence of put_by_id transitions as follows: put_by_id empty -> a put_by_id a -> b put_by_id b -> c It may be that this is the only code that refers to structures a and b. 'empty' refers to the global empty structure. Hence, a and b are almost certainly dead during any GC, while empty and c are alive. What we want the weak reference harvester to do is keep a alive so long as empty is alive, and then keep b alive so long as a is alive. The best way to do this is to allow weak reference harvesters to mark objects, and to run them to fix point.
Created attachment 115087 [details] the patch
Landed in http://trac.webkit.org/changeset/100242
You have probably already seen it, but this could be tangentially relative to ES.next weak maps: http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps They propose an ephemeron-table weak map implementation, that avoids marking the values until a key is known to be alive.
(In reply to comment #3) > You have probably already seen it, but this could be tangentially relative to ES.next weak maps: > > http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps > > They propose an ephemeron-table weak map implementation, that avoids marking the values until a key is known to be alive. It is related. :-) The big question for me is whether or not it would be wise to expose the O(n^2) implementation in this patch to the wild wild web. My code should work great mainly because its uses will be limited to optimized JIT code, which constitutes a tiny fraction of the heap. Not sure what will happen with these weak map thingies.