Move ResourceOwner on to the oilpan heap.

Move ResourceOwner on to the oilpan heap.

DocumentThreadableLoader isn't ready for oilpan, so drop its inheritance
of ResourceOwner.

This will better enable moving Resource to the oilpan heap, since
ResourceOwner can't easily support both oilpan and non-oilpan holders of
Resources if Resource is on the heap.

BUG=571190
Committed: https://crrev.com/b45282c65925dba8daaeebb93f00932c1f856709
Cr-Commit-Position: refs/heads/master@{#370214}

[Nate Chapin, 2016-01-09 00:56:06]

japhet@chromium.org changed reviewers:
+ yhirano@chromium.org

[Nate Chapin, 2016-01-09 00:56:07]

yhirano, would you mind taking a look at this? I'm not sure I've got all the
crashes fixed, but I'd like to make sure the overall strategy isn't too
obviously wrong :)

[haraken, 2016-01-10 02:40:53]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org, oilpan-reviews@chromium.org

[haraken, 2016-01-10 02:40:54]

(Let me take a look later.)

[haraken, 2016-01-12 00:22:51]

haraken@chromium.org changed reviewers:
+ sigbjornf@opera.com

[haraken, 2016-01-12 00:22:52]

I want to have Sigbjorn take another look at if the logic around PendingScript
is correct. I remember there had been a bunch of complexity around the
destruction dependency between PendingScript, HTMLScriptRunner etc. (Is the
complexity gone by introducing a pre-finalizer?)

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/ScriptLoader.cpp (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/ScriptLoader.cpp:82: dispose();

I think it's better to call detach() (i.e., it's no harm to call
m_pendingScript->releaseElementAndClear()). A pre-finalizer can call detach() as
well. Then we can remove dispose().

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLScriptRunner.cpp (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLScriptRunner.cpp:78:
m_parserBlockingScript->stopWatchingForLoad(this);

You cannot touch m_parserBlockingScript here because detach() can be called in a
destructor.

Maybe can we move the contents of the detach() to a pre-finalizer?

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:291:
clearResource();

Add a TODO to remove this once DocumentThreadableLoader becomes a ResourceOwner.

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h:151: //
DocumentThreadableLoader was ready. When DocumentThreadableLoader

Just help me understand: In what sense is it not ready?

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/LinkLoader.h (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/LinkLoader.h:85: LinkLoaderClient*
m_client;

It would be better to make LinkLoaderClient a GCMixin. Then you can use a Member
here. (You don't need to address it in this CL.)

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/TextTrackLoader.h (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/TextTrackLoader.h:90:
TextTrackLoaderClient& m_client;

It would be better to make TextTrackLoaderClient a GCMixin. Then you can use a
Member here. (You don't need to address it in this CL.)

[yhirano, 2016-01-12 07:54:49]

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceOwner.h (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceOwner.h:44: virtual
~ResourceOwner() { clearResource(); }
You cannot call clearResource() in the destructor when ResourceOwner is on-heap.
How about using pre-finalizer?

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h:151: //
DocumentThreadableLoader was ready. When DocumentThreadableLoader
On 2016/01/12 00:22:52, haraken wrote:
> 
> Just help me understand: In what sense is it not ready?

Making ThreadableLoader on-heap means making WorkerThreadableLoader on-heap. I'm
planning to propose a mechanism that mitigates cross-thread oilpan programming
difficulties and I would be happy if the class remains off-heap for a certain
time.

[Nate Chapin, 2016-01-13 20:36:33]

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/ScriptLoader.cpp (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/ScriptLoader.cpp:82: dispose();
On 2016/01/12 00:22:52, haraken wrote:
> 
> I think it's better to call detach() (i.e., it's no harm to call
> m_pendingScript->releaseElementAndClear()). A pre-finalizer can call detach()
as
> well. Then we can remove dispose().

Done.

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceOwner.h (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceOwner.h:44: virtual
~ResourceOwner() { clearResource(); }
On 2016/01/12 07:54:49, yhirano wrote:
> You cannot call clearResource() in the destructor when ResourceOwner is
on-heap.
> How about using pre-finalizer?

Done.

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLScriptRunner.cpp (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLScriptRunner.cpp:78:
m_parserBlockingScript->stopWatchingForLoad(this);
On 2016/01/12 00:22:52, haraken wrote:
> 
> You cannot touch m_parserBlockingScript here because detach() can be called in
a
> destructor.
> 
> Maybe can we move the contents of the detach() to a pre-finalizer?

Done.

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right):

https://codereview.chromium.org/1569273004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:291:
clearResource();
On 2016/01/12 00:22:52, haraken wrote:
> 
> Add a TODO to remove this once DocumentThreadableLoader becomes a
ResourceOwner.

Done.

[haraken, 2016-01-14 04:26:43]

LGTM

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceOwner.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceOwner.h:71: #endif

Nit: In this CL it is safe to call clearResource in ResoureOwner's destructor
because m_resource is still not a Member. It won't be safe once you replace the
ResourcePtr with Member in your next CL.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h:161: if
(ResourcePtr<RawResource> oldResource = m_resource) {

ResourcePtr<RawResource> oldResource = m_resource.release() ?

[yhirano, 2016-01-14 11:55:29]

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/PendingScript.cpp (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/PendingScript.cpp:169:
visitor->trace(m_streamer);
+ ResourceOwner<ScriptResource>::trace(visitor);

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/ProcessingInstruction.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/ProcessingInstruction.h:36: class
ProcessingInstruction final : public CharacterData, private
ResourceOwner<StyleSheetResource> {
+ ResourceOwner<StyleSheetResource>::trace(visitor) in the trace definition.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceOwner.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceOwner.h:46: ResourceType*
resource() const { return m_resource.get(); }
+DEFINE_INLINE_VIRTUAL_TRACE() {}

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceOwner.h:71: #endif
On 2016/01/14 04:26:43, haraken wrote:
> 
> Nit: In this CL it is safe to call clearResource in ResoureOwner's destructor
> because m_resource is still not a Member. It won't be safe once you replace
the
> ResourcePtr with Member in your next CL.

Oh, it's my fault, sorry.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLLinkElement.cpp (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLLinkElement.cpp:772:
LinkResource::trace(visitor);
+ ResourceOwner<StyleSheetResource>::trace(visitor)

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/LinkLoader.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/LinkLoader.h:53: class CORE_EXPORT
LinkLoader final : public NoBaseWillBeGarbageCollectedFinalized<LinkLoader>,
public ResourceOwner<Resource, ResourceClient>, public PrerenderClient {
+ ResourceOwner<Resource, ResourceClient>::trace(visitor) in the trace
definition.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/TextTrackLoader.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/TextTrackLoader.h:51: class
TextTrackLoader final : public
NoBaseWillBeGarbageCollectedFinalized<TextTrackLoader>, public
ResourceOwner<RawResource>, private VTTParserClient {
+ ResourceOwner<RawResource>::trace(visitor) in the trace definition.

[Nate Chapin, 2016-01-14 22:54:02]

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/PendingScript.cpp (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/PendingScript.cpp:169:
visitor->trace(m_streamer);
On 2016/01/14 11:55:29, yhirano wrote:
> + ResourceOwner<ScriptResource>::trace(visitor);

Done.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/ProcessingInstruction.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/ProcessingInstruction.h:36: class
ProcessingInstruction final : public CharacterData, private
ResourceOwner<StyleSheetResource> {
On 2016/01/14 11:55:29, yhirano wrote:
> + ResourceOwner<StyleSheetResource>::trace(visitor) in the trace definition.

Done.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceOwner.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceOwner.h:46: ResourceType*
resource() const { return m_resource.get(); }
On 2016/01/14 11:55:29, yhirano wrote:
> +DEFINE_INLINE_VIRTUAL_TRACE() {}

Done.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceOwner.h:71: #endif
On 2016/01/14 11:55:29, yhirano wrote:
> On 2016/01/14 04:26:43, haraken wrote:
> > 
> > Nit: In this CL it is safe to call clearResource in ResoureOwner's
destructor
> > because m_resource is still not a Member. It won't be safe once you replace
> the
> > ResourcePtr with Member in your next CL.
> 
> Oh, it's my fault, sorry.

Yeah, I should have caught that, too. Removing.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLLinkElement.cpp (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLLinkElement.cpp:772:
LinkResource::trace(visitor);
On 2016/01/14 11:55:29, yhirano wrote:
> + ResourceOwner<StyleSheetResource>::trace(visitor)

Done.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h:161: if
(ResourcePtr<RawResource> oldResource = m_resource) {
On 2016/01/14 04:26:43, haraken wrote:
> 
> ResourcePtr<RawResource> oldResource = m_resource.release() ?

ResourcePtr<> doesn't have release(), and if we're deleting it soon, I don't
think it's worthwhile to add it.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/LinkLoader.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/LinkLoader.h:53: class CORE_EXPORT
LinkLoader final : public NoBaseWillBeGarbageCollectedFinalized<LinkLoader>,
public ResourceOwner<Resource, ResourceClient>, public PrerenderClient {
On 2016/01/14 11:55:29, yhirano wrote:
> + ResourceOwner<Resource, ResourceClient>::trace(visitor) in the trace
> definition.

Done.

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/TextTrackLoader.h (right):

https://codereview.chromium.org/1569273004/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/TextTrackLoader.h:51: class
TextTrackLoader final : public
NoBaseWillBeGarbageCollectedFinalized<TextTrackLoader>, public
ResourceOwner<RawResource>, private VTTParserClient {
On 2016/01/14 11:55:29, yhirano wrote:
> + ResourceOwner<RawResource>::trace(visitor) in the trace definition.

Done.

[yhirano, 2016-01-15 00:44:45]

lgtm

[Nate Chapin, 2016-01-15 00:45:05]

The CQ bit was checked by japhet@chromium.org

[Nate Chapin, 2016-01-15 00:45:06]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/1569273004/#ps180001
(title: "Speculative win trybot compile fix")

[commit-bot: I haz the power, 2016-01-15 00:45:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/180001

[commit-bot: I haz the power, 2016-01-15 01:55:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-15 01:55:43]

Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Nate Chapin, 2016-01-15 17:04:35]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2016-01-15 17:05:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/180001

[commit-bot: I haz the power, 2016-01-15 18:48:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-15 18:48:27]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Nate Chapin, 2016-01-15 23:24:19]

The CQ bit was checked by japhet@chromium.org

[Nate Chapin, 2016-01-15 23:24:19]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, yhirano@chromium.org
Link to the patchset: https://codereview.chromium.org/1569273004/#ps200001
(title: "Another speculative win compile fix")

[commit-bot: I haz the power, 2016-01-15 23:25:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/200001

[commit-bot: I haz the power, 2016-01-15 23:29:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-15 23:29:07]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Nate Chapin, 2016-01-15 23:32:19]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2016-01-15 23:33:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/200001

[commit-bot: I haz the power, 2016-01-16 00:33:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-16 00:33:49]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Nate Chapin, 2016-01-16 00:38:16]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2016-01-16 00:39:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/200001

[commit-bot: I haz the power, 2016-01-16 00:45:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-16 00:45:46]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Nate Chapin, 2016-01-16 00:55:55]

The CQ bit was checked by japhet@chromium.org

[Nate Chapin, 2016-01-16 00:55:55]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, yhirano@chromium.org
Link to the patchset: https://codereview.chromium.org/1569273004/#ps220001
(title: "Speculative compile fix #3")

[commit-bot: I haz the power, 2016-01-16 00:56:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/220001

[commit-bot: I haz the power, 2016-01-16 01:21:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-16 01:21:01]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Nate Chapin, 2016-01-19 20:26:11]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-19 20:27:41]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/240001

[commit-bot: I haz the power, 2016-01-19 21:05:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-19 21:05:20]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Nate Chapin, 2016-01-19 21:10:32]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-19 21:11:54]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/260001

[Nate Chapin, 2016-01-19 21:44:51]

OK, I think have my compile woes fixed. I moved PendingScript::Type to become
ScriptStreamer::Type, since PendingScript::Type was not actually used in
PendingScript. This allows me to resolve a circular #include problem.

ScriptStreamer::Type still feels slightly out of place, but less so than it did
before :)

[haraken, 2016-01-19 21:52:20]

On 2016/01/19 21:44:51, Nate Chapin wrote:
> OK, I think have my compile woes fixed. I moved PendingScript::Type to become
> ScriptStreamer::Type, since PendingScript::Type was not actually used in
> PendingScript. This allows me to resolve a circular #include problem.
> 
> ScriptStreamer::Type still feels slightly out of place, but less so than it
did
> before :)

Still LGTM

[commit-bot: I haz the power, 2016-01-19 22:35:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-19 22:35:58]

Dry run: This issue passed the CQ dry run.

[Nate Chapin, 2016-01-19 22:36:15]

The CQ bit was checked by japhet@chromium.org

[Nate Chapin, 2016-01-19 22:36:15]

The patchset sent to the CQ was uploaded after l-g-t-m from yhirano@chromium.org
Link to the patchset: https://codereview.chromium.org/1569273004/#ps260001
(title: "win_chromium_compile_dbg_ng is the worst")

[commit-bot: I haz the power, 2016-01-19 22:38:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1569273004/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1569273004/260001

[commit-bot: I haz the power, 2016-01-19 22:48:09]

Committed patchset #14 (id:260001)

[commit-bot: I haz the power, 2016-01-19 22:49:59]

Description was changed from

==========
Move ResourceOwner on to the oilpan heap.

DocumentThreadableLoader isn't ready for oilpan, so drop its inheritance
of ResourceOwner.

This will better enable moving Resource to the oilpan heap, since
ResourceOwner can't easily support both oilpan and non-oilpan holders of
Resources if Resource is on the heap.

BUG=571190
==========

to

==========
Move ResourceOwner on to the oilpan heap.

DocumentThreadableLoader isn't ready for oilpan, so drop its inheritance
of ResourceOwner.

This will better enable moving Resource to the oilpan heap, since
ResourceOwner can't easily support both oilpan and non-oilpan holders of
Resources if Resource is on the heap.

BUG=571190

Committed: https://crrev.com/b45282c65925dba8daaeebb93f00932c1f856709
Cr-Commit-Position: refs/heads/master@{#370214}
==========

[commit-bot: I haz the power, 2016-01-19 22:50:00]

Patchset 14 (id:??) landed as
https://crrev.com/b45282c65925dba8daaeebb93f00932c1f856709
Cr-Commit-Position: refs/heads/master@{#370214}