Bug 128050 - Keep only captured symbols in CodeBlock symbol tables.
Summary: Keep only captured symbols in CodeBlock symbol tables.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andreas Kling
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-01 14:00 PST by Andreas Kling
Modified: 2014-02-03 16:08 PST (History)
4 users (show)

See Also:


Attachments
Patch (4.74 KB, patch)
2014-02-01 14:08 PST, Andreas Kling
ggaren: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kling 2014-02-01 14:00:01 PST
Keep only captured symbols in CodeBlock symbol tables.
Comment 1 Andreas Kling 2014-02-01 14:08:40 PST
Created attachment 222890 [details]
Patch
Comment 2 Geoffrey Garen 2014-02-01 14:41:17 PST
Comment on attachment 222890 [details]
Patch

It looks like the code already dropped uncaptured symbols, and you've changed its approach to reuse an existing table and remove items, rather than create a new table and selectively insert items.

Have I read that right?

What's the motivation for that change? Is there some other object that points to the BytecodeGenrator's SymbolTable? Or do you think removal will be more efficient than creating a copy or something?

(If another object also points to the BytecodeGenrator's symbol table, I think a clearer solution might be to separate that object, and force it to clone the SymbolTable as well.)
Comment 3 Andreas Kling 2014-02-01 14:59:42 PST
(In reply to comment #2)
> (From update of attachment 222890 [details])
> It looks like the code already dropped uncaptured symbols, and you've changed its approach to reuse an existing table and remove items, rather than create a new table and selectively insert items.
> 
> Have I read that right?
> 
> What's the motivation for that change? Is there some other object that points to the BytecodeGenrator's SymbolTable? Or do you think removal will be more efficient than creating a copy or something?
> 
> (If another object also points to the BytecodeGenrator's symbol table, I think a clearer solution might be to separate that object, and force it to clone the SymbolTable as well.)

The purpose of this change is to minimize the amount of memory used by SymbolTables hanging off of UnlinkedCodeBlocks. We currently keep the full symbol tables around, despite only ever accessing the captured symbols.

FWIW the reason we clone the SymbolTable in the first place is to avoid watchpoint reuse.
Comment 4 Andreas Kling 2014-02-02 15:53:51 PST
How about this:

* Rename CodeBlock::symbolTable() into CodeBlock::capturedSymbolTable().
* Fork off a CapturedSymbolTable class from SymbolTable.
* CapturedSymbolTable inherits from UnconditionalFinalizer.
* WatchpointCleanup goes away (IIUC the JSGlobalObject symbol table doesn't need this mechanism.)
* Fork off a CapturedSymbolTableEntry class from SymbolTableEntry.
* CapturedSymbolTableEntry always has a watchpoint set. SymbolTableEntry never has a watchpoint set.
* Slim/fat logic in both classes disappears.
Comment 5 Geoffrey Garen 2014-02-03 12:03:58 PST
Comment on attachment 222890 [details]
Patch

r=me because this patch is better than the status quo.

I think it would be even better to make a new SymbolTable, and just copy the captured things into it. (In the common case, nothing will be captured, so that will be faster.)
Comment 6 Geoffrey Garen 2014-02-03 12:05:34 PST
(In reply to comment #4)
> How about this:
> 
> * Rename CodeBlock::symbolTable() into CodeBlock::capturedSymbolTable().
> * Fork off a CapturedSymbolTable class from SymbolTable.
> * CapturedSymbolTable inherits from UnconditionalFinalizer.
> * WatchpointCleanup goes away (IIUC the JSGlobalObject symbol table doesn't need this mechanism.)
> * Fork off a CapturedSymbolTableEntry class from SymbolTableEntry.
> * CapturedSymbolTableEntry always has a watchpoint set. SymbolTableEntry never has a watchpoint set.
> * Slim/fat logic in both classes disappears.

I think this is right, but I think the JSGlobalObject symbol table will still need to be the version of symbol table that has an UnconditionalFinalizer.
Comment 7 Geoffrey Garen 2014-02-03 12:06:24 PST
I also think it would be nice for the BytecodeGenerator to stop sharing its SymbolTable* with some other object. Instead, BytecodeGenerator should create its own symbol table, and perform an explicit copy if any other object needs that data.
Comment 8 Andreas Kling 2014-02-03 16:08:12 PST
Committed r163337: <http://trac.webkit.org/changeset/163337>