Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2401893002:
[wrapper-tracing] WebGL and friends: Add write barriers (Closed)
|
Created:
4 years, 2 months ago by Michael Lippautz Modified:
4 years, 2 months ago CC:
ajuma+watch-canvas_chromium.org, blink-reviews, blink-reviews-html_chromium.org, Rik, chromium-reviews, dglazkov+blink, dshwang, Hannes Payer (out of office), Justin Novosad, Kai Ninomiya, Zhenyao Mo Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Description[wrapper-tracing] WebGL and friends: Add write barriers
The patch adds the write barriers needed to run wrapper tracing incrementally.
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
Committed: https://crrev.com/ad3f8c43888ff242c0afa96faf64a05de7227a5c
Cr-Commit-Position: refs/heads/master@{#426456}
Patch Set 1 #
Total comments: 2
Patch Set 2 : Addressed comment #Patch Set 3 : Rework to use TraceWrapperMember #
Total comments: 3
Patch Set 4 : Add wrappers for TextureUnitState #Patch Set 5 : Rebase #Patch Set 6 : Add missing write barrier found by the tests. #Patch Set 7 : Rebase #Messages
Total messages: 49 (27 generated)
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers BUG= ========== to ========== [wrapper-tracing] WebGL and friends: Add write barriers BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel ==========
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers 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] WebGL and friends: Add write barriers 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 ==========
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers 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] WebGL and friends: Add write barriers Correctness will be verified using the ScriptWrappableVisitorVerifier which runs on debug builds. 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 ==========
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers Correctness will be verified using the ScriptWrappableVisitorVerifier which runs on debug builds. 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] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. Correctness will be verified using the ScriptWrappableVisitorVerifier which runs on debug builds. 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 ==========
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. Correctness will be verified using the ScriptWrappableVisitorVerifier which runs on debug builds. 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] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. Correctness will be verified using the ScriptWrappableVisitorVerifier which runs on debug builds. 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 ==========
mlippautz@chromium.org changed reviewers: + haraken@chromium.org, hlopko@chromium.org, kbr@chromium.org
And these are the write barriers needed for incremental wrapper tracing. As stated in the description, correctness will happen by running in debug mode (which automatically enables the verifier).
lgtm https://codereview.chromium.org/2401893002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp (right): https://codereview.chromium.org/2401893002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp:283: ScriptWrappableVisitor::writeBarrier(this, m_context); Nit: Can we move write barrier up to line 277?
https://codereview.chromium.org/2401893002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp (right): https://codereview.chromium.org/2401893002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp:283: ScriptWrappableVisitor::writeBarrier(this, m_context); On 2016/10/07 12:34:58, Marcel Hlopko wrote: > Nit: Can we move write barrier up to line 277? Done.
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
LGTM However, I begin to realize that we should have a way to detect missing write barriers in a more reliable manner...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
On 2016/10/07 14:02:08, haraken wrote: > LGTM > > However, I begin to realize that we should have a way to detect missing write > barriers in a more reliable manner... I totally agree. Let's talk about this in more at the next meeting.
I'm not sure what the semantics are of this function. Does it need to be called each time one ScriptWrappable takes a reference to another, both direct and indirect? It looks to me like a bunch of places are missed -- WebGLFramebuffer is a container object like WebGLProgram, and needs to refer to its attachments. WebGL2RenderingContextBase is entirely missed in this CL. (The WebGL 2.0 conformance tests are run on the optional tryservers; they take too long to run on every Chromium CL.)
Thanks for the reviews! Testing: Currently we need to run locally with some other CL patched in as we add those barriers one by one. The trybots cannot find anything yet because the barrier is behind a flag. We will get an FYI bot with the flag enabled soon (crbug.com/652688). On 2016/10/07 18:12:43, Ken Russell wrote: > I'm not sure what the semantics are of this function. Does it need to be called > each time one ScriptWrappable takes a reference to another, both direct and > indirect? > ScriptWrappableVisitor::writeBarrier is an incremental marking barrier. It is needed when a field in a black object gets assigned a white one. Regular tracing takes care of recursively marking an object graph, the barrier makes sure that when new objects get assigned to already marked ones, we start marking them. Thus we need to cover the places where we assign values to members that are traced. Imho it's non-trivial for non-GC people to do that and that's why we are still discussing ways to automate, or at least statically verify correctness. We have a verifier in place that determine upon executing whether we missed a barrier (also providing a hint which barrier was missed). > It looks to me like a bunch of places are missed -- WebGLFramebuffer is a > container object like WebGLProgram, and needs to refer to its attachments. > WebGL2RenderingContextBase is entirely missed in this CL. (The WebGL 2.0 > conformance tests are run on the optional tryservers; they take too long to run > on every Chromium CL.) The barriers for WebGLFramebuffer (attachments) and WebGL2RenderingContextBase (all traced members) are indeed missing. I remember going through them, so I probably forgot to upload them. Will do that on Monday.
On 2016/10/07 18:31:38, Michael Lippautz wrote: > Thanks for the reviews! > > Testing: Currently we need to run locally with some other CL patched in as we > add those barriers one by one. The trybots cannot find anything yet because the > barrier is behind a flag. We will get an FYI bot with the flag enabled soon > (crbug.com/652688). > > On 2016/10/07 18:12:43, Ken Russell wrote: > > I'm not sure what the semantics are of this function. Does it need to be > called > > each time one ScriptWrappable takes a reference to another, both direct and > > indirect? > > > > ScriptWrappableVisitor::writeBarrier is an incremental marking barrier. It is > needed when a field in a black object gets assigned a white one. Regular tracing > takes care of recursively marking an object graph, the barrier makes sure that > when new objects get assigned to already marked ones, we start marking them. > > Thus we need to cover the places where we assign values to members that are > traced. Imho it's non-trivial for non-GC people to do that and that's why we are > still discussing ways to automate, or at least statically verify correctness. We > have a verifier in place that determine upon executing whether we missed a > barrier (also providing a hint which barrier was missed). Thanks for this info. It's confusing to me that a member assignment at the C++/Oilpan level requires a write barrier at the JavaScript wrapper level since there aren't direct references between those JavaScript wrappers -- those are implicit due to the references at the C++ level. Anyway, I trust your judgment. Is any of this written up somewhere?
On 2016/10/07 18:53:31, Ken Russell wrote: > On 2016/10/07 18:31:38, Michael Lippautz wrote: > > Thanks for the reviews! > > > > Testing: Currently we need to run locally with some other CL patched in as we > > add those barriers one by one. The trybots cannot find anything yet because > the > > barrier is behind a flag. We will get an FYI bot with the flag enabled soon > > (crbug.com/652688). > > > > On 2016/10/07 18:12:43, Ken Russell wrote: > > > I'm not sure what the semantics are of this function. Does it need to be > > called > > > each time one ScriptWrappable takes a reference to another, both direct and > > > indirect? > > > > > > > ScriptWrappableVisitor::writeBarrier is an incremental marking barrier. It is > > needed when a field in a black object gets assigned a white one. Regular > tracing > > takes care of recursively marking an object graph, the barrier makes sure that > > when new objects get assigned to already marked ones, we start marking them. > > > > Thus we need to cover the places where we assign values to members that are > > traced. Imho it's non-trivial for non-GC people to do that and that's why we > are > > still discussing ways to automate, or at least statically verify correctness. > We > > have a verifier in place that determine upon executing whether we missed a > > barrier (also providing a hint which barrier was missed). > > Thanks for this info. It's confusing to me that a member assignment at the > C++/Oilpan level requires a write barrier at the JavaScript wrapper level since > there aren't direct references between those JavaScript wrappers -- those are > implicit due to the references at the C++ level. > > Anyway, I trust your judgment. Is any of this written up somewhere? Yeah, let's have a good comment on ScriptWrappableVisitor. Honestly speaking, we were assuming that the number of places we need to add the write barriers would be very limited and thus okay, but it has turned out that's not the case (that's why we're experimenting this behind a flag). We're now discussing a way to introduce a better static/runtime verification for write barriers or re-think about what we're doing.
So we have a manual: http://docs/document/d/1NAUFfejfJIkTVGXxM2QPwNqWczHi81eE83PaPcsl3pM/edit#head... But as Kentaro wrote, we are investigating a more robust approach, so thing might change.
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. Correctness will be verified using the ScriptWrappableVisitorVerifier which runs on debug builds. 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] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. 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 ==========
PTAL: We are now using the TraceWrapperMember type (where possible) https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp (right): https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp:1776: ScriptWrappableVisitor::writeBarrier(this, texture); TextureUnitState didn't use Member<> types before. I didn't add the TraceWrapperMembers since I assume having raw pointers is needed for fast construction/passing around somewhere?
https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp (right): https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp:1776: ScriptWrappableVisitor::writeBarrier(this, texture); On 2016/10/12 10:57:12, Michael Lippautz wrote: > TextureUnitState didn't use Member<> types before. I didn't add the > TraceWrapperMembers since I assume having raw pointers is needed for fast > construction/passing around somewhere? How about changing Member<>s in TextureUnitState to TraceWrapperMember<>s? Won't it work?
All converted. Last case uncovered an issue :) For most parts I am quite happy with the current approach. https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp (right): https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp:1776: ScriptWrappableVisitor::writeBarrier(this, texture); On 2016/10/12 11:51:28, haraken wrote: > On 2016/10/12 10:57:12, Michael Lippautz wrote: > > TextureUnitState didn't use Member<> types before. I didn't add the > > TraceWrapperMembers since I assume having raw pointers is needed for fast > > construction/passing around somewhere? > > How about changing Member<>s in TextureUnitState to TraceWrapperMember<>s? Won't > it work? Done. This exposes one corner case where the compiler doesn't warn us: Pre-sized containers. The problem is that when we resize a HeapVector we initialize it with empty elements. Unlike with ::append (where the signature makes sure we have the proper types), it is ok to assign a raw value to m_vector[i] because of the operator= overload for raw values. Raw assignments (not going through TraceWrapperMember(this, ...)) to empty TraceWrapperMembers lack the parent pointer and a DCHECK will fire. 2 options: (a) Be fine with that this one case fails at runtime. (b) Remove the overload for raw values, effectively forcing us to always go through TraceWrapperMember(..) on aissgnment. I'd like to stay with (a).
On 2016/10/12 12:50:38, Michael Lippautz wrote: > All converted. Last case uncovered an issue :) For most parts I am quite happy > with the current approach. > > https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... > File third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp > (right): > > https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... > third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp:1776: > ScriptWrappableVisitor::writeBarrier(this, texture); > On 2016/10/12 11:51:28, haraken wrote: > > On 2016/10/12 10:57:12, Michael Lippautz wrote: > > > TextureUnitState didn't use Member<> types before. I didn't add the > > > TraceWrapperMembers since I assume having raw pointers is needed for fast > > > construction/passing around somewhere? > > > > How about changing Member<>s in TextureUnitState to TraceWrapperMember<>s? > Won't > > it work? > > Done. > > This exposes one corner case where the compiler doesn't warn us: Pre-sized > containers. > > The problem is that when we resize a HeapVector we initialize it with empty > elements. Unlike with ::append (where the signature makes sure we have the > proper types), it is ok to assign a raw value to m_vector[i] because of the > operator= overload for raw values. Raw assignments (not going through > TraceWrapperMember(this, ...)) to empty TraceWrapperMembers lack the parent > pointer and a DCHECK will fire. > > 2 options: > (a) Be fine with that this one case fails at runtime. > (b) Remove the overload for raw values, effectively forcing us to always go > through TraceWrapperMember(..) on aissgnment. > > I'd like to stay with (a). Would it be helpful to set canInitializeWithMemset for WrapperMember<> to false? https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/heap/... Then the Vector won't be initialized with memset. It always calls constructors.
On 2016/10/12 13:42:03, haraken wrote: > On 2016/10/12 12:50:38, Michael Lippautz wrote: > > All converted. Last case uncovered an issue :) For most parts I am quite happy > > with the current approach. > > > > > https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... > > File third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp > > (right): > > > > > https://codereview.chromium.org/2401893002/diff/40001/third_party/WebKit/Sour... > > third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp:1776: > > ScriptWrappableVisitor::writeBarrier(this, texture); > > On 2016/10/12 11:51:28, haraken wrote: > > > On 2016/10/12 10:57:12, Michael Lippautz wrote: > > > > TextureUnitState didn't use Member<> types before. I didn't add the > > > > TraceWrapperMembers since I assume having raw pointers is needed for fast > > > > construction/passing around somewhere? > > > > > > How about changing Member<>s in TextureUnitState to TraceWrapperMember<>s? > > Won't > > > it work? > > > > Done. > > > > This exposes one corner case where the compiler doesn't warn us: Pre-sized > > containers. > > > > The problem is that when we resize a HeapVector we initialize it with empty > > elements. Unlike with ::append (where the signature makes sure we have the > > proper types), it is ok to assign a raw value to m_vector[i] because of the > > operator= overload for raw values. Raw assignments (not going through > > TraceWrapperMember(this, ...)) to empty TraceWrapperMembers lack the parent > > pointer and a DCHECK will fire. > > > > 2 options: > > (a) Be fine with that this one case fails at runtime. > > (b) Remove the overload for raw values, effectively forcing us to always go > > through TraceWrapperMember(..) on aissgnment. > > > > I'd like to stay with (a). > > Would it be helpful to set canInitializeWithMemset for WrapperMember<> to false? > > https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/heap/... > > Then the Vector won't be initialized with memset. It always calls constructors. Calling the ctor doesn't help as we don't know which back pointer to use. This problem arises because HeapVector and friends are transient data structures not really taking part in wrapper tracing. If they had support (+ ctors adding a back pointer) then we could make these calls work seamlessly. Not sure we want to go there now.
Makes sense. This looks much, much nicer. LGTM.
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Going to land this now. FYI: The failures in PS5 showed the detection of a missing WB at runtime for the case we cannot emit a compile time failure (pre-sized heapvectors). E.g.: #0 0x7fc1b9785a9e base::debug::StackTrace::StackTrace() #1 0x7fc1b979e3eb logging::LogMessage::~LogMessage() #2 0x7fc1bc7e1ff6 blink::TraceWrapperMember<>::operator=<>() #3 0x7fc1bc7e1dd9 WTF::HashTable<>::add<>() Misses the wrapping type ==> #4 0x7fc1bc7df5db blink::WebGLFramebuffer::setAttachmentInternal() #5 0x7fc1bc7df3cc blink::WebGLFramebuffer::setAttachmentForBoundFramebuffer() #6 0x7fc1bc7f3a3c blink::WebGLRenderingContextBase::framebufferRenderbuffer() #7 0x7fc1bc3aa618 blink::WebGLRenderingContextV8Internal::framebufferRenderbufferMethodCallback() #8 0x7fc1b80fb020 v8::internal::FunctionCallbackArguments::Call() #9 0x7fc1b819743b v8::internal::(anonymous namespace)::HandleApiCallHelper<>() #10 0x7fc1b81962a5 v8::internal::Builtin_Impl_HandleApiCall() #11 0x7fc1b8195e82 v8::internal::Builtin_HandleApiCall() #12 0x1ff3c8c843a7 <unknown>
LGTM from my standpoint, though I'd like to stress the importance for public documentation on this stuff so our team knows how to maintain the code. A search for "oilpan tracewrappermember" turns up 4 hits total.
On 2016/10/20 04:28:29, Ken Russell wrote: > LGTM from my standpoint, though I'd like to stress the importance for public > documentation on this stuff so our team knows how to maintain the code. A search > for "oilpan tracewrappermember" turns up 4 hits total. Sure, there will be a doc for devs on how to prepare the code for wrapper tracing.
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by mlippautz@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from hlopko@chromium.org, haraken@chromium.org, kbr@chromium.org Link to the patchset: https://chromiumcodereview.appspot.com/2401893002/#ps120001 (title: "Rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. 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] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. 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 ==========
Message was sent while issue was closed.
Committed patchset #7 (id:120001)
Message was sent while issue was closed.
Description was changed from ========== [wrapper-tracing] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. 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] WebGL and friends: Add write barriers The patch adds the write barriers needed to run wrapper tracing incrementally. 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 Committed: https://crrev.com/ad3f8c43888ff242c0afa96faf64a05de7227a5c Cr-Commit-Position: refs/heads/master@{#426456} ==========
Message was sent while issue was closed.
Patchset 7 (id:??) landed as https://crrev.com/ad3f8c43888ff242c0afa96faf64a05de7227a5c Cr-Commit-Position: refs/heads/master@{#426456} |
