[Webkit-unassigned] [Bug 73712] PODIntervalTree takes 1.7MB memory on www.nytimes.com

[bugzilla-daemon at webkit.org]

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





--- Comment #15 from Yongjun Zhang <yongjun_zhang at apple.com>  2011-12-09 10:00:10 PST ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > > I agree.  How about we make a special cased PODArena for the PODIntervalTree that we know for sure each entry will have the same size, and keep the generalize case as it is?  That way we fix the memory issue without violating the invariants of PODArena.
> > > 
> > > Yes, you could subclass PODArena into PODFreeListArena<T> which only supports allocations and frees of a particular type. But would you give my suggestion about clearing out the arena some thought?
> > 
> > I was thinking to have Document hold up to a shared PODFreeListArena<T> and the arena will get cleared when the document is destroyed.
> 
> That wasn't my point -- I'm suggesting to not add the free list functionality at all, keep the arena class simple, and at opportune times, clear out the shared arena. The question is whether there is a good point during layout to clear the arena because we know that we are going to clear out and recompute all of the floating object sets.

If the shared arena is per document, looks like it is hard to find such a point that we could clear the arena before tearing down the entire render tree.  m_placedFloatsTree is needed for layout involved with its owning renderblock and we can only reliably clear this tree when its owning renderblock is destroyed.  That means we have to wait all PODIntervalTree's get destroyed before we can clear the shared arena, and probably also means we are going to throw away the whole render tree anyway.

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