On 2012/10/29 15:40:48, Yang wrote:
On 2012/10/29 06:24:57, Yury Semikhatsky wrote:
> On 2012/10/26 17:42:55, loislo wrote:
> > new version was uploaded
>
> It would make sense to also add a test for the case that Yang mentioned
when
> existing external string is converted to a symbol.
I sensed some pitfalls in this issue, so I discussed it with Erik.
Summary:
The reason we have an external string table (EST) is so that at a late
phase
(B)
of GC, we check which strings in the EST is alive, and call the dispose
callback
on those that are not (and remove them from the EST).
In a prior phase (A) we also do that for strings in the symbol table: if
we
find
dead external strings in the symbol table, we call its dispose callback.
Consider an external string that has been turned into a symbol (case 1):
it's
both in the EST and in the symbol table. When it dies, both phases (A)
and (B)
stumble upon it and call its callback, but only A actually succeeds in
calling
the callback, since it's then set to NULL so that (B) ignores it.
A symbol that has been externalized (case 2) is only dealt with in (A),
since
it's not in the EST. The reason is that this way we can save space in the
EST.
Visiting both the symbol table and the EST potentionally overvisits
strings of
case 1.
The question is, is overvisiting a problem? If not, we can just do that.
If
yes,
we have some options:
1) not deal with external strings in (A) and always add case 2 strings to
the
EST, which increases the required space in the EST.
2) remove case 1 strings from the EST, which is kind of expensive
3) visit strings in the EST first and ignore those that are symbols, since
those
are in the symbol table, that we visit thereafter.
I strongly favor the third option. Sorry about the incorrect comment I
gave
earlier!
I implemented option 3 in https://chromiumcodereview.appspot.com/11340010/
https://chromiumcodereview.appspot.com/11315004/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
