Introduce InlinedGlobalMarkingVisitor

Introduce InlinedGlobalMarkingVisitor

This CL introduces InlinedGlobalMarkingVisitor to devirtualize and inline
the most common Visitor implementation, MarkingVisitor<GlobalMarking>.

BUG=420515

[kouhei (in TOK), 2014-12-12 05:49:02]

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

[kouhei (in TOK), 2014-12-12 05:49:02]

WIP. This is a "preview" of inlining/devirtualizing
MarkingVisitor<GlobalMarking>.
This CL improves BlinkGC.stress-large-SVGLengthList test by 25%.

The implementation in heap/ is obviously not complete, but hopefully PS1 will
give some rough idea on how the trace methods on GC classes will be modified.
I'd appreciate if you would take a look on svg/ changes and give me feedback.
Thanks!

[haraken, 2014-12-12 06:07:31]

On 2014/12/12 05:49:02, kouhei wrote:
> WIP. This is a "preview" of inlining/devirtualizing
> MarkingVisitor<GlobalMarking>.
> This CL improves BlinkGC.stress-large-SVGLengthList test by 25%.

25% in marking time, or 25% in total execution time? Either way, this looks like
a great improvement.

> The implementation in heap/ is obviously not complete, but hopefully PS1 will
> give some rough idea on how the trace methods on GC classes will be modified.
> I'd appreciate if you would take a look on svg/ changes and give me feedback.

I think this CL is a right way to go.

Let me ask a couple of questions:

- GC_PLUGIN_IGNORE("") is going to be removed, right?

- What's a difference between DEFINE_TRACE(X), DEFINE_INLINE_TRACE(,override)
and DEFINE_INLINE_TRACE(virtual,)? Do we need to distinguish them?

- What's the difference in binary size of release builds? Can you roughly
estimate how much this change will increase the binary size if we apply the
macros to all trace methods in the code base?

[kouhei (in TOK), 2014-12-15 03:20:03]

On 2014/12/12 06:07:31, haraken wrote:
> On 2014/12/12 05:49:02, kouhei wrote:
> > WIP. This is a "preview" of inlining/devirtualizing
> > MarkingVisitor<GlobalMarking>.
> > This CL improves BlinkGC.stress-large-SVGLengthList test by 25%.
> 
> 25% in marking time, or 25% in total execution time? Either way, this looks
like
> a great improvement.
25% in marking time, as the test only measures GC marking time.

> > The implementation in heap/ is obviously not complete, but hopefully PS1
will
> > give some rough idea on how the trace methods on GC classes will be
modified.
> > I'd appreciate if you would take a look on svg/ changes and give me
feedback.
> 
> I think this CL is a right way to go.
Thanks!

> Let me ask a couple of questions:
> 
> - GC_PLUGIN_IGNORE("") is going to be removed, right?
Yes. They are going to be removed.

> - What's a difference between DEFINE_TRACE(X), DEFINE_INLINE_TRACE(,override)
> and DEFINE_INLINE_TRACE(virtual,)? Do we need to distinguish them?
DECLARE_TRACE(X) replaces trace() declaration in X.h
DEFINE_INLINE_TRACE() replaces inline trace definition in X.h
DEFINE_TRACE() replaces trace definition in X.cpp

> - What's the difference in binary size of release builds? Can you roughly
> estimate how much this change will increase the binary size if we apply the
> macros to all trace methods in the code base?
There are about 1530 trace() definitions, and each of them currently around 64
bytes are expected to double its size, so roughly 100kB binary size increase is
expected.