559311 - [HTML5] nsContentUtils::CreateContextualFragment doesn't cache HTML5 parser properly

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Based on Shark profiles nsContentSink::Init (or calls under it) takes
6.3% of setting .innerHTML.
Seems like most of the time is spent in getting some prefs.

This isn't really HTML5 parser bug, but shows up when using html5 parser and
testing innerHTML.

A bit dummy testcase is here https://bug404385.bugzilla.mozilla.org/attachment.cgi?id=289857

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

For some reason nsHtml5Module::NewHtml5Parser() seems to be called a lot.
Parser should be cached, but somehow it is not.

Patch coming.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Modifying summary, since the problem is really about not-caching the parser.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Fragment parser should be cached *after* it has been used and even if GetFragmentParser is called

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

http://hg.mozilla.org/mozilla-central/rev/d9d7de04f75d

Comment 5

[Jim Jeffery not reading bug-mail 1/2/11]

I think this patch caused bug 559683

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I'll backout this for now until the reason for bug 559683 is found.
It sounds like an HTML5 parser issue.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

http://hg.mozilla.org/mozilla-central/rev/ec1616d0be38

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Jim, if you could try now whether you can still reproduce bug 559683.
(I've seen bug 559683 too. Very annoying bug.)

Comment 9

[Jim Jeffery not reading bug-mail 1/2/11]

With the backout all is good again.  Ran the browser overnight with my normal set of tabs, and all is good this morning, no leaks/creep on memory use.

Comment 10

[Henri Sivonen (:hsivonen)]

Attachment: Drop held elements at the end of ParseFragment

I expect this patch to fix the memory problem.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 440206 [details] [diff] [review]
Drop held elements at the end of ParseFragment

I've been running a build with both these patches for 16h now and
tbpl hasn't cause any major memory increase.
So perhaps we could land both patches.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

http://hg.mozilla.org/mozilla-central/rev/08bd8eb86673
http://hg.mozilla.org/mozilla-central/rev/d16525937c8b

Jim , if you still see the fast increase in memory usage, please reopen this 
(or bug 559683).

Comment 13

[Jim Jeffery not reading bug-mail 1/2/11]

Marking this Verified Fixed,  been running solid here past two days with no memory creep. 

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre ID:20100423040128