[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview: https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRkRDFwBc/edit#gid=0&vpid=A3

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
TEST=WebglConformance_conformance_misc_expando_loss,WebglConformance_conformance2_misc_expando_loss_2

Committed: https://crrev.com/36f8241df16763eb6512ffcce71a070073469521
Cr-Commit-Position: refs/heads/master@{#423821}

[Michael Lippautz, 2016-10-06 14:07:59]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

BUG=
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[Michael Lippautz, 2016-10-06 14:17:42]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in 
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[Michael Lippautz, 2016-10-06 14:17:52]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in 
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[Michael Lippautz, 2016-10-06 14:22:01]

Patchset #1 (id:1) has been deleted

[Michael Lippautz, 2016-10-06 14:22:05]

Patchset #1 (id:20001) has been deleted

[Michael Lippautz, 2016-10-06 14:22:41]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[Michael Lippautz, 2016-10-06 14:27:05]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[Michael Lippautz, 2016-10-06 14:45:37]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[Michael Lippautz, 2016-10-06 17:49:54]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
TEST=WebglConformance_conformance_misc_expando_loss,WebglConformance_conformance2_misc_expando_loss_2
==========

[Michael Lippautz, 2016-10-06 17:54:53]

mlippautz@chromium.org changed reviewers:
+ haraken@chromium.org, hlopko@chromium.org, kbr@chromium.org

[Michael Lippautz, 2016-10-06 17:54:54]

PTAL

kbr: fyi, we are now going through the code base once again, updating all the
bindings that changed since May and adding write barriers for incremental
marking (will be a follow up if needed).

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp:550:
visitor->traceWrappers(attachment.value->object());
I mirrored the object grouping behavior here by directly retaining
WebGLAttachment::object(). Should we also keep the intermediate WebGLAttachment?

[Ken Russell (switch to Gerrit), 2016-10-06 19:05:14]

LGTM to unblock you -- the code changes look correct -- but two high-level
questions.

Are there sufficient tests to cover these changes? The following WebGL
conformance tests are supposed to make sure these wrappers are preserved:

conformance/misc/expando-loss.html
conformance2/misc/expando-loss-2.html

and all of the tests in conformance/extensions/ and conformance2/extensions/ .

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGL2RenderingContext.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContext.cpp:167:
WebGL2RenderingContextBase::traceWrappers(visitor);
The fact that this bug could happen is an indication that we should strive to
eliminate duplicated code between DEFINE_TRACE and DEFINE_TRACE_WRAPPERS. See
below.

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp
(right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp:4264:
DEFINE_TRACE_WRAPPERS(WebGL2RenderingContextBase) {
It's unfortunate that basically exactly the same code has to be written in
DEFINE_TRACE and DEFINE_TRACE_WRAPPERS. Can you think of a way to use templates
to have one template method that can be instantiated twice, each time with a
different method pointer, and invoke that method pointer against the incoming
visitor argument? If the objects that are traced, and how they're traced, could
be made the same between these two methods, that would make it more feasible.
See below.

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp:4278:
visitor->traceWrappers(buf);
The tracing of the HeapVectors is different from the Oilpan tracing above in
DEFINE_TRACE. Is the Oilpan version wrong (or is this one)? Do they have to be
different, or could for example a template traceWrappers method be added to
HeapVector which would be present if the target type is ScriptWrappable (or
Member of ScriptWrappable)?

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp:550:
visitor->traceWrappers(attachment.value->object());
On 2016/10/06 17:54:54, Michael Lippautz wrote:
> I mirrored the object grouping behavior here by directly retaining
> WebGLAttachment::object(). Should we also keep the intermediate
WebGLAttachment?
> 

There's no JavaScript wrapper for it, so that's not necessary.

[Michael Lippautz, 2016-10-06 19:58:13]

Thanks for the review!

I ran the expando-loss and expando-loss-2 tests already and made sure they pass
with --enable-runtime-features=TraceWrappables (also vice versa: they fail when
some tracing is missing).

Will check the extensions.

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGL2RenderingContext.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContext.cpp:167:
WebGL2RenderingContextBase::traceWrappers(visitor);
On 2016/10/06 19:05:14, Ken Russell wrote:
> The fact that this bug could happen is an indication that we should strive to
> eliminate duplicated code between DEFINE_TRACE and DEFINE_TRACE_WRAPPERS. See
> below.

Acknowledged.

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp
(right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp:4264:
DEFINE_TRACE_WRAPPERS(WebGL2RenderingContextBase) {
On 2016/10/06 19:05:14, Ken Russell wrote:
> It's unfortunate that basically exactly the same code has to be written in
> DEFINE_TRACE and DEFINE_TRACE_WRAPPERS. Can you think of a way to use
templates
> to have one template method that can be instantiated twice, each time with a
> different method pointer, and invoke that method pointer against the incoming
> visitor argument? If the objects that are traced, and how they're traced,
could
> be made the same between these two methods, that would make it more feasible.
> See below.

It's exactly the code because all members here (and I think WebGL in general)
are of type ScriptWrappable. In cases where you would have only a few
ScriptWrappable wrapper tracing could be significantly faster than regular
tracing.

Having said that, I totally agree that we should do something about the
duplication (templates, macros,... ). Right now the priorities are on
completeness to get tracing into a state where we can ship.

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp:4278:
visitor->traceWrappers(buf);
On 2016/10/06 19:05:14, Ken Russell wrote:
> The tracing of the HeapVectors is different from the Oilpan tracing above in
> DEFINE_TRACE. Is the Oilpan version wrong (or is this one)? Do they have to be
> different, or could for example a template traceWrappers method be added to
> HeapVector which would be present if the target type is ScriptWrappable (or
> Member of ScriptWrappable)?

Regular Oilpan tracing is integrated into HeapVector, i.e., it traces each slot
of the vector. Wrapper tracing still lacks these infrastructure features. So
both a correct :)

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp:550:
visitor->traceWrappers(attachment.value->object());
On 2016/10/06 19:05:14, Ken Russell wrote:
> On 2016/10/06 17:54:54, Michael Lippautz wrote:
> > I mirrored the object grouping behavior here by directly retaining
> > WebGLAttachment::object(). Should we also keep the intermediate
> WebGLAttachment?
> > 
> 
> There's no JavaScript wrapper for it, so that's not necessary.

Yep, it's not necessary. 

I guess my question is whether we should try to avoid shortcuts and follow the
object graph (in this case, make WebGLAttachment tracable and trace the object()
in there), or just mirror what object grouping did.

I am fine with both.

[Ken Russell (switch to Gerrit), 2016-10-07 03:00:55]

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp:550:
visitor->traceWrappers(attachment.value->object());
On 2016/10/06 19:58:13, Michael Lippautz wrote:
> On 2016/10/06 19:05:14, Ken Russell wrote:
> > On 2016/10/06 17:54:54, Michael Lippautz wrote:
> > > I mirrored the object grouping behavior here by directly retaining
> > > WebGLAttachment::object(). Should we also keep the intermediate
> > WebGLAttachment?
> > > 
> > 
> > There's no JavaScript wrapper for it, so that's not necessary.
> 
> Yep, it's not necessary. 
> 
> I guess my question is whether we should try to avoid shortcuts and follow the
> object graph (in this case, make WebGLAttachment tracable and trace the
object()
> in there), or just mirror what object grouping did.
> 
> I am fine with both.

Let's just mirror what object grouping did -- i.e., don't add a traceWrappers to
WebGLAttachment. That class is an implementation detail and it makes sense to me
that traceWrappers should really only be added to ScriptWrappables.

[Ken Russell (switch to Gerrit), 2016-10-07 03:01:50]

Still LGTM of course.

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp
(right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp:4264:
DEFINE_TRACE_WRAPPERS(WebGL2RenderingContextBase) {
On 2016/10/06 19:58:13, Michael Lippautz wrote:
> On 2016/10/06 19:05:14, Ken Russell wrote:
> > It's unfortunate that basically exactly the same code has to be written in
> > DEFINE_TRACE and DEFINE_TRACE_WRAPPERS. Can you think of a way to use
> templates
> > to have one template method that can be instantiated twice, each time with a
> > different method pointer, and invoke that method pointer against the
incoming
> > visitor argument? If the objects that are traced, and how they're traced,
> could
> > be made the same between these two methods, that would make it more
feasible.
> > See below.
> 
> It's exactly the code because all members here (and I think WebGL in general)
> are of type ScriptWrappable. In cases where you would have only a few
> ScriptWrappable wrapper tracing could be significantly faster than regular
> tracing.
> 
> Having said that, I totally agree that we should do something about the
> duplication (templates, macros,... ). Right now the priorities are on
> completeness to get tracing into a state where we can ship.

OK -- sounds fine.

[haraken, 2016-10-07 04:48:49]

LGTM

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp
(right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp:4264:
DEFINE_TRACE_WRAPPERS(WebGL2RenderingContextBase) {
On 2016/10/07 03:01:50, Ken Russell wrote:
> On 2016/10/06 19:58:13, Michael Lippautz wrote:
> > On 2016/10/06 19:05:14, Ken Russell wrote:
> > > It's unfortunate that basically exactly the same code has to be written in
> > > DEFINE_TRACE and DEFINE_TRACE_WRAPPERS. Can you think of a way to use
> > templates
> > > to have one template method that can be instantiated twice, each time with
a
> > > different method pointer, and invoke that method pointer against the
> incoming
> > > visitor argument? If the objects that are traced, and how they're traced,
> > could
> > > be made the same between these two methods, that would make it more
> feasible.
> > > See below.
> > 
> > It's exactly the code because all members here (and I think WebGL in
general)
> > are of type ScriptWrappable. In cases where you would have only a few
> > ScriptWrappable wrapper tracing could be significantly faster than regular
> > tracing.
> > 
> > Having said that, I totally agree that we should do something about the
> > duplication (templates, macros,... ). Right now the priorities are on
> > completeness to get tracing into a state where we can ship.
> 
> OK -- sounds fine.

Yeah, in general, things traced by traceWrapper()s should be much fewer than
things traced by trace()s.

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp:550:
visitor->traceWrappers(attachment.value->object());
On 2016/10/07 03:00:55, Ken Russell wrote:
> On 2016/10/06 19:58:13, Michael Lippautz wrote:
> > On 2016/10/06 19:05:14, Ken Russell wrote:
> > > On 2016/10/06 17:54:54, Michael Lippautz wrote:
> > > > I mirrored the object grouping behavior here by directly retaining
> > > > WebGLAttachment::object(). Should we also keep the intermediate
> > > WebGLAttachment?
> > > > 
> > > 
> > > There's no JavaScript wrapper for it, so that's not necessary.
> > 
> > Yep, it's not necessary. 
> > 
> > I guess my question is whether we should try to avoid shortcuts and follow
the
> > object graph (in this case, make WebGLAttachment tracable and trace the
> object()
> > in there), or just mirror what object grouping did.
> > 
> > I am fine with both.
> 
> Let's just mirror what object grouping did -- i.e., don't add a traceWrappers
to
> WebGLAttachment. That class is an implementation detail and it makes sense to
me
> that traceWrappers should really only be added to ScriptWrappables.

We've already added a bunch of traceWrappers to non-ScriptWrappables, because we
sometimes need to tell DOM-side reachability to V8.

That being said, I don't have any strong opinion about how
WebGLFramebuffer::traceWrappers should be written. The current CL looks fine.

[Ken Russell (switch to Gerrit), 2016-10-07 04:58:52]

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp (right):

https://codereview.chromium.org/2392313004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webgl/WebGLFramebuffer.cpp:550:
visitor->traceWrappers(attachment.value->object());
On 2016/10/07 04:48:49, haraken wrote:
> On 2016/10/07 03:00:55, Ken Russell wrote:
> > On 2016/10/06 19:58:13, Michael Lippautz wrote:
> > > On 2016/10/06 19:05:14, Ken Russell wrote:
> > > > On 2016/10/06 17:54:54, Michael Lippautz wrote:
> > > > > I mirrored the object grouping behavior here by directly retaining
> > > > > WebGLAttachment::object(). Should we also keep the intermediate
> > > > WebGLAttachment?
> > > > > 
> > > > 
> > > > There's no JavaScript wrapper for it, so that's not necessary.
> > > 
> > > Yep, it's not necessary. 
> > > 
> > > I guess my question is whether we should try to avoid shortcuts and follow
> the
> > > object graph (in this case, make WebGLAttachment tracable and trace the
> > object()
> > > in there), or just mirror what object grouping did.
> > > 
> > > I am fine with both.
> > 
> > Let's just mirror what object grouping did -- i.e., don't add a
traceWrappers
> to
> > WebGLAttachment. That class is an implementation detail and it makes sense
to
> me
> > that traceWrappers should really only be added to ScriptWrappables.
> 
> We've already added a bunch of traceWrappers to non-ScriptWrappables, because
we
> sometimes need to tell DOM-side reachability to V8.
> 
> That being said, I don't have any strong opinion about how
> WebGLFramebuffer::traceWrappers should be written. The current CL looks fine.
> 

OK. I don't have a strong opinion on this.

[Michael Lippautz, 2016-10-07 07:15:02]

The CQ bit was checked by mlippautz@chromium.org

[commit-bot: I haz the power, 2016-10-07 07:15:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-07 09:04:19]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
TEST=WebglConformance_conformance_misc_expando_loss,WebglConformance_conformance2_misc_expando_loss_2
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
TEST=WebglConformance_conformance_misc_expando_loss,WebglConformance_conformance2_misc_expando_loss_2
==========

[commit-bot: I haz the power, 2016-10-07 09:04:20]

Committed patchset #2 (id:60001)

[commit-bot: I haz the power, 2016-10-07 09:06:09]

Description was changed from

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
TEST=WebglConformance_conformance_misc_expando_loss,WebglConformance_conformance2_misc_expando_loss_2
==========

to

==========
[wrapper-tracing] Add tracing to WebGLRenderingContextBase and friends

Port object grouping changes introduced in
https://crrev.com/b7615cfadeb59ac220bd5994d4ec6f99341452f0 to tracing.

Note: Write barriers for incremental tracing will be added in a follow up.

Overview:
https://docs.google.com/spreadsheets/d/1RhLiHF9Pnw7Zx8EijuR0LruPkeiVJIXXi0eRk...

BUG=chromium:468240
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
TEST=WebglConformance_conformance_misc_expando_loss,WebglConformance_conformance2_misc_expando_loss_2

Committed: https://crrev.com/36f8241df16763eb6512ffcce71a070073469521
Cr-Commit-Position: refs/heads/master@{#423821}
==========

[commit-bot: I haz the power, 2016-10-07 09:06:10]

Patchset 2 (id:??) landed as
https://crrev.com/36f8241df16763eb6512ffcce71a070073469521
Cr-Commit-Position: refs/heads/master@{#423821}