prepare |SVGDocumentExtensions::m_relativeLengthSVGRoots| for oilpan

Prepare |SVGDocumentExtensions::m_relativeLengthSVGRoots| for oilpan

|SVGDocumentExtensions::m_relativeLengthSVGRoots| is made a HashSet<Member<SVGSVGELement> > in oilpan.
This is valid in oilpan, because document and <svg> elements are guaranteed to die at the same time. When a <svg> element is removed from the document, |SVGSVGElement::removedFrom| would remove itself from the set.

BUG=357163
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175865

[haraken, 2014-06-09 09:37:55]

https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
File Source/core/svg/SVGDocumentExtensions.h (right):

https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
Source/core/svg/SVGDocumentExtensions.h:113:
WillBeHeapHashSet<RawPtrWillBeWeakMember<SVGSVGElement> >
m_relativeLengthSVGRoots; // Root SVG elements with relative length descendants.

Just help me understand: How is the weak processing implemented in non-oilpan
builds? I couldn't find code that calls
removeSVGRootWithRelativeLengthDescendents from some SVGSVGElement's destructor.

(It makes sense to make this a hash set of weak members, but I'd like to
understand the background.)

[kouhei (in TOK), 2014-06-09 09:53:46]

https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
File Source/core/svg/SVGDocumentExtensions.h (right):

https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
Source/core/svg/SVGDocumentExtensions.h:113:
WillBeHeapHashSet<RawPtrWillBeWeakMember<SVGSVGElement> >
m_relativeLengthSVGRoots; // Root SVG elements with relative length descendants.
On 2014/06/09 09:37:55, haraken wrote:
> 
> Just help me understand: How is the weak processing implemented in non-oilpan
> builds? I couldn't find code that calls
> removeSVGRootWithRelativeLengthDescendents from some SVGSVGElement's
destructor.
> 
> (It makes sense to make this a hash set of weak members, but I'd like to
> understand the background.)
if (document is dead && <svg> is dead) the stale ptr in hashset is deleted
anyway
if (document is alive && <svg> is dead) <svg>::removedFrom handles this
if (document is dead && <svg> is alive) the stale ptr in hashset is deleted
anyway 
if (document is alive && <svg> is alive) no need to remove

[haraken, 2014-06-09 10:41:05]

On 2014/06/09 09:53:46, kouhei wrote:
>
https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
> File Source/core/svg/SVGDocumentExtensions.h (right):
> 
>
https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
> Source/core/svg/SVGDocumentExtensions.h:113:
> WillBeHeapHashSet<RawPtrWillBeWeakMember<SVGSVGElement> >
> m_relativeLengthSVGRoots; // Root SVG elements with relative length
descendants.
> On 2014/06/09 09:37:55, haraken wrote:
> > 
> > Just help me understand: How is the weak processing implemented in
non-oilpan
> > builds? I couldn't find code that calls
> > removeSVGRootWithRelativeLengthDescendents from some SVGSVGElement's
> destructor.
> > 
> > (It makes sense to make this a hash set of weak members, but I'd like to
> > understand the background.)
> if (document is dead && <svg> is dead) the stale ptr in hashset is deleted
> anyway
> if (document is alive && <svg> is dead) <svg>::removedFrom handles this
> if (document is dead && <svg> is alive) the stale ptr in hashset is deleted
> anyway 
> if (document is alive && <svg> is alive) no need to remove

I know what this CL is doing. My question is how the weak processing is
implemented in the current non-oilpan code. I want to make sure that this CL
doesn't change existing behavior.

Nit:
> if (document is dead && <svg> is alive) the stale ptr in hashset is deleted
> anyway 

This shouldn't happen, since the document and <svg> should die in the same GC
cycle in oilpan builds.

[kouhei (in TOK), 2014-06-10 05:24:37]

https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
File Source/core/svg/SVGDocumentExtensions.h (right):

https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
Source/core/svg/SVGDocumentExtensions.h:113:
WillBeHeapHashSet<RawPtrWillBeWeakMember<SVGSVGElement> >
m_relativeLengthSVGRoots; // Root SVG elements with relative length descendants.
On 2014/06/09 09:53:46, kouhei wrote:
> On 2014/06/09 09:37:55, haraken wrote:
> > 
> > Just help me understand: How is the weak processing implemented in
non-oilpan
> > builds? I couldn't find code that calls
> > removeSVGRootWithRelativeLengthDescendents from some SVGSVGElement's
> destructor.
> > 
> > (It makes sense to make this a hash set of weak members, but I'd like to
> > understand the background.)
> if (document is dead && <svg> is dead) the stale ptr in hashset is deleted
> anyway
> if (document is alive && <svg> is dead) <svg>::removedFrom handles this
> if (document is dead && <svg> is alive) the stale ptr in hashset is deleted
> anyway 
> if (document is alive && <svg> is alive) no need to remove

Discussed offline. Made this a strong ref to be explicit that this map never
outlive its referenced elements.

[haraken, 2014-06-10 05:28:03]

LGTM.

On 2014/06/10 05:24:37, kouhei wrote:
>
https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
> File Source/core/svg/SVGDocumentExtensions.h (right):
> 
>
https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
> Source/core/svg/SVGDocumentExtensions.h:113:
> WillBeHeapHashSet<RawPtrWillBeWeakMember<SVGSVGElement> >
> m_relativeLengthSVGRoots; // Root SVG elements with relative length
descendants.
> On 2014/06/09 09:53:46, kouhei wrote:
> > On 2014/06/09 09:37:55, haraken wrote:
> > > 
> > > Just help me understand: How is the weak processing implemented in
> non-oilpan
> > > builds? I couldn't find code that calls
> > > removeSVGRootWithRelativeLengthDescendents from some SVGSVGElement's
> > destructor.
> > > 
> > > (It makes sense to make this a hash set of weak members, but I'd like to
> > > understand the background.)
> > if (document is dead && <svg> is dead) the stale ptr in hashset is deleted
> > anyway
> > if (document is alive && <svg> is dead) <svg>::removedFrom handles this
> > if (document is dead && <svg> is alive) the stale ptr in hashset is deleted
> > anyway 
> > if (document is alive && <svg> is alive) no need to remove
> 
> Discussed offline. Made this a strong ref to be explicit that this map never
> outlive its referenced elements.

Please explain that in the CL description.

[kouhei (in TOK), 2014-06-10 05:36:06]

On 2014/06/10 05:28:03, haraken wrote:
> LGTM.
> 
> On 2014/06/10 05:24:37, kouhei wrote:
> >
>
https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
> > File Source/core/svg/SVGDocumentExtensions.h (right):
> > 
> >
>
https://codereview.chromium.org/323803002/diff/1/Source/core/svg/SVGDocumentE...
> > Source/core/svg/SVGDocumentExtensions.h:113:
> > WillBeHeapHashSet<RawPtrWillBeWeakMember<SVGSVGElement> >
> > m_relativeLengthSVGRoots; // Root SVG elements with relative length
> descendants.
> > On 2014/06/09 09:53:46, kouhei wrote:
> > > On 2014/06/09 09:37:55, haraken wrote:
> > > > 
> > > > Just help me understand: How is the weak processing implemented in
> > non-oilpan
> > > > builds? I couldn't find code that calls
> > > > removeSVGRootWithRelativeLengthDescendents from some SVGSVGElement's
> > > destructor.
> > > > 
> > > > (It makes sense to make this a hash set of weak members, but I'd like to
> > > > understand the background.)
> > > if (document is dead && <svg> is dead) the stale ptr in hashset is deleted
> > > anyway
> > > if (document is alive && <svg> is dead) <svg>::removedFrom handles this
> > > if (document is dead && <svg> is alive) the stale ptr in hashset is
deleted
> > > anyway 
> > > if (document is alive && <svg> is alive) no need to remove
> > 
> > Discussed offline. Made this a strong ref to be explicit that this map never
> > outlive its referenced elements.
> 
> Please explain that in the CL description.
Done.

[kouhei (in TOK), 2014-06-10 05:36:13]

The CQ bit was checked by kouhei@chromium.org

[commit-bot: I haz the power, 2014-06-10 05:37:08]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kouhei@chromium.org/323803002/20001

[commit-bot: I haz the power, 2014-06-10 06:35:29]

Change committed as 175865