More special handling of the symbol table during garbage collection....

More special handling of the symbol table during garbage collection.

Mark all objects reachable from the symbols except the symbols
themselves as live (and reachable from strong roots).  This ensures
that if the symbol itself remains alive for any reason, and if it was
a sliced string or cons string backed by an external string, then the
external string will be strongly reachable and therefore not get a
weak reference callback.


Committed: http://code.google.com/p/v8/source/detail?r=1846

[Mads Ager (chromium), 2009-05-04 17:51:58]

LGTM

[iposva, 2009-05-04 17:54:46]

Drive by comments about this implementation. We should probably take this now to
roll out a fix quickly, but then address the issue raised here about collection
order.

-Ivan

http://codereview.chromium.org/100344/diff/1/3
File src/mark-compact.cc (right):

http://codereview.chromium.org/100344/diff/1/3#newcode588
Line 588: // not receive a weak reference callback.
In retrospect was that not always a problem even with regular non-external
strings only being referred to by a sliced string in the symbol table?

http://codereview.chromium.org/100344/diff/1/3#newcode601
Line 601: SetMark(symbol_table);
The flipping of mark bits to marked and back to unmarked seems fragile to me.
Currently this only works because of the order (symbol table walking being
first.)

Since we need to handle the symbol table in a special way. The direct references
are not marked but any depending ones. Can we add a special marker instead? That
way we would not be depending on resetting mark bits during a GC, which is an
unneeded break of the assertions of the GC algorithm and adds unknown ordering
dependencies in the marking steps making the code more complex.

[Kevin Millikin (Chromium), 2009-05-04 18:34:52]

http://codereview.chromium.org/100344/diff/1/3
File src/mark-compact.cc (right):

http://codereview.chromium.org/100344/diff/1/3#newcode588
Line 588: // not receive a weak reference callback.
I don't think so.  The problem was that the weak reference callback was getting
called for the external string.  With no callback, there should not be any (err,
this) problem.

http://codereview.chromium.org/100344/diff/1/3#newcode601
Line 601: SetMark(symbol_table);
This was just the simplest implementation to get a fix out asap.  It leverages
all the existing infrastructure for recursive marking and handling (the
admittedly as close to impossible as possible) marking stack overflow. I agree
that it's dodgy.