Oilpan: Implement bitmap marking

Oilpan: Implement bitmap marking

Not for parallel marking, but for improving memory locality.

BUG=420515

[haraken, 2014-11-21 07:33:35]

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

[haraken, 2014-11-21 07:33:35]

I ran a couple of benchmarks where marking time matters and confirmed that the
bitmap marking slightly regresses performance. For example,
shadow_dom/LargeDistributionWithoutLayout.html regresses by 5%. I guess that the
regression would be due to the overhead of looking up a BaseHeapPage from a
tracing object (i.e.,
pageHeaderFromObject(this)->markObject(reinterpret_cast<Address>(this)) in
HeapObjectHeader::mark()).

I don't think that the implementation of the patch set 1 is fully optimized
(e.g., markObject() is a virtual function), but at least I can say that the
bitmap marking won't give us a big win.

[sof, 2014-12-05 13:44:01]

sigbjornf@opera.com changed reviewers:
+ sigbjornf@opera.com

[sof, 2014-12-05 13:44:01]

What is the current thinking as regards this CL? I've held off from getting to
grips with it due to the so-so results initially reported.

Would be useful to get some oilpan_gc_times metrics for it.

[haraken, 2014-12-05 15:26:55]

On 2014/12/05 13:44:01, sof wrote:
> What is the current thinking as regards this CL? I've held off from getting to
> grips with it due to the so-so results initially reported.
> 
> Would be useful to get some oilpan_gc_times metrics for it.

As far as I manually measured time consumed in marking, this CL slows down
marking. So I don't have a plan to land this CL in the current shape at least.

One thing I might want to experiment is:

- Prepare heaps for fixed-size objects (a heap for 8 byte objects, a heap for 16
byte objects, a heap for 24 byte objects, ...).
- Put only object payloads on the heap and allocate their headers in a separate
space (which means that we do something like bitmap marking using the header
space). By doing this, we can pack more objects in our heaps and thus improve
locality of accessing the objects (e.g., Node traversals).

I'm now collecting performance numbers to see if this kind of optimization would
make sense.

[sof, 2014-12-05 18:51:31]

On 2014/12/05 15:26:55, haraken wrote:
> On 2014/12/05 13:44:01, sof wrote:
> > What is the current thinking as regards this CL? I've held off from getting
to
> > grips with it due to the so-so results initially reported.
> > 
> > Would be useful to get some oilpan_gc_times metrics for it.
> 
> As far as I manually measured time consumed in marking, this CL slows down
> marking. So I don't have a plan to land this CL in the current shape at least.
> 

It's puzzling why that would be.

> One thing I might want to experiment is:
> 
> - Prepare heaps for fixed-size objects (a heap for 8 byte objects, a heap for
16
> byte objects, a heap for 24 byte objects, ...).
> - Put only object payloads on the heap and allocate their headers in a
separate
> space (which means that we do something like bitmap marking using the header
> space). By doing this, we can pack more objects in our heaps and thus improve
> locality of accessing the objects (e.g., Node traversals).
> 

Thanks for the update, I wondered about the status of this CL when you mentioned
sectioning off object headers, as they do travel along similar lines. You're
generalizing it in some manner, I suppose.

> I'm now collecting performance numbers to see if this kind of optimization
would
> make sense.

Great, that's the way to go about it :-) Eager to hear what comes out/up.