Incremental GCInfo descriptor table expansion.

Incremental GCInfo descriptor table expansion.

The Oilpan GC infrastructure keeps a GCInfo descriptor per garbage
allocated class, with heap object headers referring to their descriptor
by way of a table index. 15 bits are currently set aside for these
indices.

Incrementally expand the underlying table rather than allocate it all
upfront.

R=haraken
BUG=446582
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=187992

[sof, 2015-01-07 14:22:12]

sigbjornf@opera.com changed reviewers:
+ oilpan-reviews@chromium.org

[sof, 2015-01-07 14:22:12]

Please take a look.

[haraken, 2015-01-07 15:45:42]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2015-01-07 15:45:43]

The 2^15*sizeof(GCInfo*) table is consuming 256 KB, which seems a waste, so this
looks like a good fix.

LGTM.

https://codereview.chromium.org/820693006/diff/20001/Source/platform/heap/Vis...
File Source/platform/heap/Visitor.cpp (right):

https://codereview.chromium.org/820693006/diff/20001/Source/platform/heap/Vis...
Source/platform/heap/Visitor.cpp:50: // holding its index. Duplicate GCInfo
slots might be written for the

ah, this is a good point...

BTW, I begin to wonder why TSan doesn't complain about a race on s_gcInfoMap[].

[sof, 2015-01-07 15:56:17]

On 2015/01/07 15:45:43, haraken wrote:
> The 2^15*sizeof(GCInfo*) table is consuming 256 KB, which seems a waste, so
this
> looks like a good fix.
> 

Just trying a few sites, I couldn't exceed a 512 table size.

[sof, 2015-01-07 18:57:49]

https://codereview.chromium.org/820693006/diff/20001/Source/platform/heap/Vis...
File Source/platform/heap/Visitor.cpp (right):

https://codereview.chromium.org/820693006/diff/20001/Source/platform/heap/Vis...
Source/platform/heap/Visitor.cpp:50: // holding its index. Duplicate GCInfo
slots might be written for the
On 2015/01/07 15:45:43, haraken wrote:
> 
> ah, this is a good point...
> 
> BTW, I begin to wonder why TSan doesn't complain about a race on
s_gcInfoMap[].

Yes, -fno-threadsafe-statics would be in effect there too. But it looks benign
to update the static int, even though we may waste an extra GCInfo slot.

Will land this now, but run it past tsan in parallel.

[sof, 2015-01-07 18:57:55]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2015-01-07 18:58:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/820693006/20001

[commit-bot: I haz the power, 2015-01-07 20:23:17]

Committed patchset #2 (id:20001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=187992