[Webkit-unassigned] [Bug 93612] New: Introduce node proxy classes and make the parser use them.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Aug 9 05:37:07 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=93612

           Summary: Introduce node proxy classes and make the parser use
                    them.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: skyul at company100.net


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list