WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
93612
Introduce node proxy classes and make the parser use them.
https://bugs.webkit.org/show_bug.cgi?id=93612
Summary
Introduce node proxy classes and make the parser use them.
Kwang Yul Seo
Reported
2012-08-09 05:37:32 PDT
When the parser runs in speculation mode, it can't actually create elements because element creation has visible side effects such as registering image or form elements. So speculative parser must be able to pump the tokenizer and run the tree builder without performing DOM modiciations. The parser needs to queue DOM modifications and run them all if the speculation ends up succeeding. Currently, each item of the stack of open elements and the active formatting element list has a pointer to its element. Thanks to
r123577
and its follow-up patches, we no longer read tag names and attributes from these elements, but we still has the element pointer because we perform DOM modifications on it. To queue even element creation, we need a way to refer to an element without actually creating it. So I added proxy nodes in this patch. A proxy node is an object which can hold a RefPtr pointer to an element. When we need to create a node, we create an empty node proxy instead and queue an element creation task that will be performed later. This element creation task creates an element and stores the element pointer into the proxy node. Now when the parser needs to refer to an element, it can refer to its node proxy instead. Only HTMLParserDOMMutationTask knows the difference between Node and NodeProxy. The rest of the parser treats a proxy node as if it is a real node. This is okay because we never (and must not) call DOM operations outside HTMLParserDOMMutationQueue. We have 5 node proxy classes with the same class hierarchy as Node. They essentially play the same role but I added subclasses because I wanted to keep the type information present in the current code. NodeProxy itself is also ref-counted to prevent memory leak. Node proxies are similar to content handles used in Firefox's HTML parsing threading implementation, but they differ in that contents handles stick around for the life time of the parser and have no type information. A content handle is just a pointer to a pointer to an element (nsIContent**). Refer to
https://developer.mozilla.org/en-US/docs/Gecko/HTML_parser_threading
"Memory Management When Crossing the Thread Boundary" for further information. Changed HTMLParserDOMMutationQueue to queue element creation in speculation mode.
Attachments
Patch
(125.98 KB, patch)
2012-08-09 05:41 PDT
,
Kwang Yul Seo
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Kwang Yul Seo
Comment 1
2012-08-09 05:41:54 PDT
Created
attachment 157454
[details]
Patch
Eric Seidel (no email)
Comment 2
2013-03-05 02:03:11 PST
We took a different approach with the threaded parser work. I think this is now WONTFIX/dupe of
bug 106127
.
Zan Dobersek
Comment 3
2013-09-05 08:33:51 PDT
Comment on
attachment 157454
[details]
Patch The work on this bug has ceased, removing the r? flag on the patch.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug