Open
Bug 515941
Opened 15 years ago
Updated 2 years ago
[HTML5] Release script-removed parser-inserted nodes that aren't on the tree builder stack
Categories
(Core :: DOM: HTML Parser, defect, P3)
Core
DOM: HTML Parser
Tracking
()
NEW
People
(Reporter: hsivonen, Unassigned)
References
Details
(Whiteboard: [MemShrink:P3])
Considering comet use cases, the parser shouldn't keep alive nodes that a script has removed from the DOM and that aren't any longer on the parser stack.
Reporter | ||
Updated•15 years ago
|
Priority: -- → P3
Comment 1•13 years ago
|
||
So are there any technical problem to just not fix this?
Whiteboard: [MemShrink]
Reporter | ||
Comment 2•13 years ago
|
||
Fixing this would involve writing a special-purpose garbage collector for the content handles making it works so that it works right with two threads involved but without locking the threads too much.
Comment 3•13 years ago
|
||
Could the mainthread/cycle collector thread lock parser thread occasionally and
traverse/unlink something in the parser thread?
CC doesn't happen too often. And hopefully the locking could happen only for certain documents/parsers.
Also, I can still misunderstand how bad or not-bad this bug is.
Can this lead to keep some elements alive as long as the page is being parsed?
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #3)
> Could the mainthread/cycle collector thread lock parser thread occasionally
> and traverse/unlink something in the parser thread?
Locking the world occasionally an option, but I'd implement the garbage collection as a sweep over the parser's data structures and rewriting the active handles to point to new backing storage (and then destroying the old backing storage) instead of using CC itself.
> Can this lead to keep some elements alive as long as the page is being
> parsed?
Yes. This leads to all elements created by a parser being alive as long as that parser is still active even if a script has removed the elements from the DOM.
Anyway, to answer your first question properly: The reason this hasn't been done yet is that the amount of work required to fix this is large relative to how often the problem might actually appear. After all, this is a total non-issue for the vast, vast majority of HTML documents.
Updated•13 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P3]
Reporter | ||
Updated•6 years ago
|
Assignee: hsivonen → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•