Oilpan: move WorkerThreadStartupData to the oilpan heap.

Oilpan: move WorkerThreadStartupData to the oilpan heap.

R=vegorov@chromium.org,tkent@chromium.org
BUG=340522
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=168903

[sof, 2014-03-10 14:32:13]

Please take a look.

[Vyacheslav Egorov (Chromium), 2014-03-11 00:12:03]

lgtm

[michaeln, 2014-03-11 00:28:25]

WorkerThreadStartupData isn't a DOM object, so i'm wondering, why move a class
like this to the oilpan heap... just curious?

[haraken, 2014-03-11 03:34:49]

LGTM

[tkent, 2014-03-11 05:36:47]

sigbjornf@, what's the benefit of making WorkerThreadStartupData
garbage-collected? Will you make its data members garbage-collected?

[sof, 2014-03-11 06:11:21]

On 2014/03/11 05:36:47, tkent wrote:
> sigbjornf@, what's the benefit of making WorkerThreadStartupData
> garbage-collected? Will you make its data members garbage-collected?

Curious question, is the plan to have a mixed/balanced heap usage in the end &
selectively move objects to a smaller GCed heap that are problematic to manage,
lifetime-wise?

It's mostly a static structure right now, and there aren't too many instances.
But, having its 'clients' be managed through heap pointer relationships will
provide some value/benefit eventually, I reckon.

[tkent, 2014-03-11 06:56:35]

On 2014/03/11 06:11:21, sof wrote:
> On 2014/03/11 05:36:47, tkent wrote:
> > sigbjornf@, what's the benefit of making WorkerThreadStartupData
> > garbage-collected? Will you make its data members garbage-collected?
> 
> Curious question, is the plan to have a mixed/balanced heap usage in the end &
> selectively move objects to a smaller GCed heap that are problematic to
manage,
> lifetime-wise?

I don't think we should move everything to oilpan now with oilpan transition
types. The transition types disturb other developers.

> It's mostly a static structure right now, and there aren't too many instances.
> But, having its 'clients' be managed through heap pointer relationships will
> provide some value/benefit eventually, I reckon.

It makes sense. lgtm.

[sof, 2014-03-11 08:04:55]

On 2014/03/11 06:56:35, tkent wrote:
> On 2014/03/11 06:11:21, sof wrote:
> > On 2014/03/11 05:36:47, tkent wrote:
> > > sigbjornf@, what's the benefit of making WorkerThreadStartupData
> > > garbage-collected? Will you make its data members garbage-collected?
> > 
> > Curious question, is the plan to have a mixed/balanced heap usage in the end
&
> > selectively move objects to a smaller GCed heap that are problematic to
> manage,
> > lifetime-wise?
> 
> I don't think we should move everything to oilpan now with oilpan transition
> types. The transition types disturb other developers.
> 

That's a useful reminder, thanks. Requiring WorkerClients to be heap allocated
now would risk that.

[sof, 2014-03-11 08:05:04]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2014-03-11 08:05:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sigbjornf@opera.com/191003010/1

[commit-bot: I haz the power, 2014-03-11 09:18:49]

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

[commit-bot: I haz the power, 2014-03-11 09:18:49]

Try jobs failed on following builders: linux_blink

[sof, 2014-03-11 09:19:42]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2014-03-11 09:19:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sigbjornf@opera.com/191003010/1

[commit-bot: I haz the power, 2014-03-11 10:24:13]

Change committed as 168903