The transitive copy algorithm was missing support for [WeakProperty]s,
thereby ensuring that we only copy the values if the keys are reachable.
Furthermore we might need to re-hash [Expando]s - since the copied
objects start with no identity hash codes.
The CL also makes us avoid calling to Dart for each [Expando]
separately and instead use a list - just as we do in the re-hashing of
maps/sets.
We also move the C++ code to invoke rehashing logic into
DartLibraryCalls::*.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=vm/dart{,_2}/isolates/fast_object_copy{,2}_test
Change-Id: I836745feef8a6d7573faa94e29a19c1eca0c39f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209106
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The test causes flaky issues when run in parallel, it may also have
client/server races in them.
The flaky failures happen due to a socket write resulting in a "broken
pipe" exception. Normally that means the other end of the socket was
closed whent the write happens.
An attempt in [0] at fixing one of the issues seem to be unsuccessful,
since the error still happens, namely in this code:
final serverContinue = Completer();
final clientContinue = Completer();
server.listen((s) async {
await serverContinue.future;
clientContinue.complete();
});
final socket = await Socket.connect(address, server.port);
socket.write(" socket content"); // <-- This write causes a broken pipe exception!
serverContinue.complete();
await clientContinue.future;
It's unclear why that happens, since the server side certainly doesn't
close it's end of the socket.
Since this is causing "iso-stress" builder to be failing, I'll remove
this test from the stress test.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Removing test from "iso-stress" builder
Change-Id: I1f9fc130b7408d586b55699487baa3c293403217
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207134
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL
* Removes conditional Skip markers in status files
* Removes some outdated TODOs in the code
* Deletes tests/lib_2/isolate/isolate_stress_test
=> It's skipped everywhere, we no longer support isolates on web
* Fixes standalone{,_2}/io/directory_list_sync_test:
=> Instead of relying on the Platform.script which could be an ELF
file lying somewhere else, use Platform.executable instead
* Fixes standalone{,_2}/io/unix_socket_test:
=> The server used `sub.cancel()` to close it's reading end while
the client tried to write to it. This is racy.
If the server goes first, the write on client will throw (since
no error listener was installed on socket.done)
Avoid the race by coordinating client/server.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Enables more tests.
Change-Id: I0464f81f540f2eda23ef4199cc536e53e6a809b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207120
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This should make flaky timeouts of some tests go away as well as make
the vm/dart{,_2}/isolates/dart_api_create_lightweight_isolate_test test
pass in dwarf stack traces mode.
TEST=Gets flaky/failing tests to pass.
Change-Id: Iaa1fe484b01479f80f65539d04aba3b3798cad1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207022
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Running this test under TSAN can consume 15 GB of memory alone. Running
it in parallel will make the 'iso-stress' builder OOM and the bot die
with infra failure.
TEST=Should fix BOT_DIED infra failures on "iso-stress" builder.
Change-Id: I5d6a1ab99b3c4c415d1712263a29f3c70b4942e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206786
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
We use message passing as comunication mechanism between isolates.
The transitive closure of an object to be sent is currently serialized
into a snapshot form and deserialized on the receiver side. Furthermore
the receiver side will re-hash any linked hashmaps in that graph.
If isolate gropus are enabled we have all isolates in a group work on
the same heap. That removes the need to use an intermediate
serialization format. It also removes the need for an O(n) step on the
receiver side.
This CL implements a fast transitive object copy implementation and
makes use of it a message that is to be passed to another isolate stays
within the same isolate group.
In the common case the object graph will fit into new space. So the
copy algorithm will try to take advantage of it by having a fast path
and a fallback path. Both of them effectively copy the graph in BFS
order.
The algorithm works effectively like a scavenge operation, but instead
of first copying the from-object to the to-space and then re-writing the
object in to-space to forward the pointers (which requires us writing to
the to-space memory twice), we only reserve space for to-objects and
then initialize the to-objects to it's final contents, including
forwarded pointers (i.e. write the to-space object only once).
Compared with a scavenge operation (which stores forwarding pointers in
the objects themselves), we use a [WeakTable] to store them. This is the
only remaining expensive part of the algorithm and could be further
optimized. To avoid relying on iterating the to-space, we'll remember
[from, to] addresses.
=> All of this works inside a [NoSafepointOperationScope] and avoids
usages of handles as well as write barriers.
While doing the transitive object copy, we'll share any object we can
safely share (canonical objects, strings, sendports, ...) instead of
copying it.
If the fast path fails (due to allocation failure or hitting) we'll
handlify any raw pointers and continue almost the same algorithm in a
safe way, where GC is possible at every object allocation site and
normal barriers are used for any stores of object pointers.
The copy algorithm uses templates to share the copy logic between the
fast and slow case (same copy routines can work on raw pointers as well
as handles).
There's a few special things to take into consideration:
* If we copy a view on external typed data we need to know the
external typed data address to compute the inner pointer of the
view, so we'll eagerly initialize external typed data.
* All external typed data needs to get a finalizer attached
(irrespective if the object copy suceeds or not) to ensure the
`malloc()`ed data is freed again.
* Transferables will only be transferred on successful transitive
copies. Also they need to attach finalizers to objects (which
requires all objects be in handles).
* We copy linked hashmaps as they are - instead of compressing the
data by removing deleted entries. We may need to re-hash those
hashmaps on the receiver side (similar to the snapshot-based copy
approach) since new object graph will have no identity hash codes
assigned to them. Though if the hashmaps only has sharable objects
as keys (very common, e.g. json) there is no need for re-hashing.
It changes the SendPort.* benchmarks as follows:
```
Benchmark | default | IG | IG + FOC
----------------------------------------------------------------------------------------------------------------------------
SendPort.Send.Nop(RunTimeRaw): | 0.25 us (1 x) | 0.26 us (0.96 x) | 0.25 us (1.00 x)
SendPort.Send.Json.400B(RunTimeRaw): | 4.15 us (1 x) | 1.45 us (2.86 x) | 1.05 us (3.95 x)
SendPort.Send.Json.5KB(RunTimeRaw): | 82.16 us (1 x) | 27.17 us (3.02 x) | 18.32 us (4.48 x)
SendPort.Send.Json.50KB(RunTimeRaw): | 784.70 us (1 x) | 242.10 us (3.24 x) | 165.50 us (4.74 x)
SendPort.Send.Json.500KB(RunTimeRaw): | 8510.4 us (1 x) | 3083.80 us (2.76 x) | 2311.29 us (3.68 x)
SendPort.Send.Json.5MB(RunTimeRaw): | 122381.33 us (1 x) | 62959.40 us (1.94 x) | 55492.10 us (2.21 x)
SendPort.Send.BinaryTree.2(RunTimeRaw): | 1.91 us (1 x) | 0.92 us (2.08 x) | 0.72 us (2.65 x)
SendPort.Send.BinaryTree.4(RunTimeRaw): | 6.32 us (1 x) | 2.70 us (2.34 x) | 2.10 us (3.01 x)
SendPort.Send.BinaryTree.6(RunTimeRaw): | 25.24 us (1 x) | 10.47 us (2.41 x) | 8.61 us (2.93 x)
SendPort.Send.BinaryTree.8(RunTimeRaw): | 104.08 us (1 x) | 41.08 us (2.53 x) | 33.51 us (3.11 x)
SendPort.Send.BinaryTree.10(RunTimeRaw): | 373.39 us (1 x) | 174.11 us (2.14 x) | 134.75 us (2.77 x)
SendPort.Send.BinaryTree.12(RunTimeRaw): | 1588.64 us (1 x) | 893.18 us (1.78 x) | 532.05 us (2.99 x)
SendPort.Send.BinaryTree.14(RunTimeRaw): | 6849.55 us (1 x) | 3705.19 us (1.85 x) | 2507.90 us (2.73 x)
SendPort.Receive.Nop(RunTimeRaw): | 0.67 us (1 x) | 0.69 us (0.97 x) | 0.68 us (0.99 x)
SendPort.Receive.Json.400B(RunTimeRaw): | 4.37 us (1 x) | 0.78 us (5.60 x) | 0.77 us (5.68 x)
SendPort.Receive.Json.5KB(RunTimeRaw): | 45.67 us (1 x) | 0.90 us (50.74 x) | 0.87 us (52.49 x)
SendPort.Receive.Json.50KB(RunTimeRaw): | 498.81 us (1 x) | 1.24 us (402.27 x) | 1.06 us (470.58 x)
SendPort.Receive.Json.500KB(RunTimeRaw): | 5366.02 us (1 x) | 4.22 us (1271.57 x) | 4.65 us (1153.98 x)
SendPort.Receive.Json.5MB(RunTimeRaw): | 101050.88 us (1 x) | 20.81 us (4855.88 x) | 21.0 us (4811.95 x)
SendPort.Receive.BinaryTree.2(RunTimeRaw): | 3.91 us (1 x) | 0.76 us (5.14 x) | 0.74 us (5.28 x)
SendPort.Receive.BinaryTree.4(RunTimeRaw): | 9.90 us (1 x) | 0.79 us (12.53 x) | 0.76 us (13.03 x)
SendPort.Receive.BinaryTree.6(RunTimeRaw): | 33.09 us (1 x) | 0.87 us (38.03 x) | 0.84 us (39.39 x)
SendPort.Receive.BinaryTree.8(RunTimeRaw): | 126.77 us (1 x) | 0.92 us (137.79 x) | 0.88 us (144.06 x)
SendPort.Receive.BinaryTree.10(RunTimeRaw): | 533.09 us (1 x) | 0.94 us (567.12 x) | 0.92 us (579.45 x)
SendPort.Receive.BinaryTree.12(RunTimeRaw): | 2223.23 us (1 x) | 3.03 us (733.74 x) | 3.04 us (731.33 x)
SendPort.Receive.BinaryTree.14(RunTimeRaw): | 8945.66 us (1 x) | 4.03 us (2219.77 x) | 4.30 us (2080.39 x)
```
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=vm/dart{,_2}/isolates/fast_object_copy{,2}_test
Change-Id: I835c59dab573d365b8a4b9d7c5359a6ea8d8b0a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203776
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
If two mutators concurrently execute a switchable call that targets a
code object which has been disabled, they both go to runtime trying to
fix that switchable call site's object pool.
This Cl ensures we use the same logic as for other miss handlers to
ensure we properly guard against concurrent accesses.
The attached regression test will trigger a segfault - though only
with low probability.
The changes to first land is: Avoid assuming the target can be called
directly. Instead always go through IC Stub when returning from miss
handler. We do that since a call site might not provide ARGS_DESC but
the target might need it.
Fixes https://github.com/dart-lang/sdk/issues/46539
Fixes https://github.com/dart-lang/sdk/issues/46553
TEST=vm/dart{,_2}/isolates/regress_46539_test
Change-Id: I18018fa286173d905c52b6e058a6c87b544ff18e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206373
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The flag isn't used anywhere in our tests or in embedder code. Turning
it on will result in a VM startup error.
We should therefore remove all uses of the flag and the flag itself.
This is a unmodified reland of
https://dart-review.googlesource.com/c/sdk/+/204500
after some remaining g3 usages have been fixed (the flutter
roll didn't port the GN changes to BUILD changes in g3)
TEST=Existing test suite.
Change-Id: Ic28c9b334a0b04524ee57e2554cc8d713a83fbfb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204785
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
If two mutators concurrently execute a switchable call that targets a
code object which has been disabled, they both go to runtime trying to
fix that switchable call site's object pool.
This Cl ensures we use the same logic as for other miss handlers to
ensure we properly guard against concurrent accesses.
The attached regression test will trigger a segfault - though only
with low probability.
Fixes https://github.com/dart-lang/sdk/issues/46539
TEST=vm/dart{,_2}/isolates/regress_46539_test
Change-Id: I91d84d25d74fb742ea992016a581b118345dd404
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205649
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
By running the same code multiple times in isolates it will be more likely for TSAN to detect races.
TEST=Existing test suite.
Change-Id: I12a6aa3efbb2a8c5616278c96d8e292eb3b172e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205080
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This removes the need for the image snapshot writer to know the
starting memory offset of any ELF sections. Instead, relocation
and symbol information are recorded in the ELF writer to be
resolved during finalization.
This is a step towards being able to reorder sections in the
ELF memory space for better packing into segments. Delaying
relocation and symbol resolution also moves towards merging
multiple text or data sections into a single section if desired.
In addition, this CL removes redundant rows from the DWARF line
number program matrix to reduce the size of debugging information.
Originally, rows were written for every PC offset visited by the
CodeSourceMap. However, no row is needed if the source information
(file, line, column) is the same as the previously written row.
There are also fixes to Utils::{IsInt,IsUint,IsAbsoluteUint} to
allow N >= the bit size of the value.
TEST=Refactoring, so existing tests.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: I09f87cea214bca06b6fca60cd66138dae6da9e83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203766
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The regexp test does in fact always cause a StackOverflow exception to
be thrown - but only in AOT mode (the list of passing tests was
generated using JIT, which is why this one was assumed to be passing)
The http reuse port test is racy due to assumptions about being able to
reuse TCP/IP ports.
TEST=Existing test suite. Trying to get iso-stress builder green.
Change-Id: I38d1b9a2d9526ab4e6af20f5359d995c43986930
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205641
Reviewed-by: Martin Kustermann <kustermann@google.com>
We also make spawned isolate errors failures of the iso-stress builder
(not just VM crashes but also if tests that are supposed to pass fail -
for whatever reason).
TEST=Existing test coverage
Change-Id: Ie5d8d8cddf62f97b3a9b10c5368b6afa37c1cd04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205260
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Currently the TSAN JIT run runs all tests in one go, that causes the bot
to run OOM. Instead we'll run it in batches, to limit the amount of RAM
TSAN needs to accumulate until end of program.
TEST=Existing test suite.
Change-Id: I6e5b3e9201dda94bbe4deb39a9fd01c8f84329f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204983
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The call specializer replaces implicit setter calls with
AssertAssignable+StoreInstanceField. If the former lazy-deopts it will
deopt to after-call and therefore the StoreInstanceField will not be
performed.
This CL makes use of newly added infrastructure that can mark such
instructions as lazy-deopt to before-call, therefore causing a
re-try of the instance call.
Fixes https://github.com/dart-lang/sdk/issues/46446
Issue https://github.com/dart-lang/sdk/issues/45213
TEST=vm/dart{,_2}/deopt/restart_call_on_deopt_regress_46446_test
Change-Id: I460e9a3c86b89a1ae127145024ace2d3d860d0af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204721
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit b1f1aee94d.
Reason for revert: Some left-over uses in g3 need to removed first
(some were removed in b/380758599 but apparently there's some
usages left).
Original change's description:
> [vm] Remove --causal-async-stacks flag
>
> The flag isn't used anywhere in our tests or in embedder code. Turning
> it on will result in a VM startup error.
>
> We should therefore remove all uses of the flag and the flag itself.
>
> TEST=Existing test suite.
>
> Change-Id: I19dfba052df7948dfdb379c0610dab67ebbcd12d
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204500
> Reviewed-by: Clement Skau <cskau@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
TBR=kustermann@google.com,cskau@google.com
Change-Id: I03aad46f46153d5ea4ac2fcdd5685d0ef2a0d9af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204723
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The flag isn't used anywhere in our tests or in embedder code. Turning
it on will result in a VM startup error.
We should therefore remove all uses of the flag and the flag itself.
TEST=Existing test suite.
Change-Id: I19dfba052df7948dfdb379c0610dab67ebbcd12d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204500
Reviewed-by: Clement Skau <cskau@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Right now RegExps get compiled to code like this:
v1 <- Constant(<igoto offset table (int32 array)>)
v2 <- InstanceCall([], ...)
v3 <- InstanceCall([], v1, v2)
IndirectGoto(v3)
The [InstanceCall]s can go to runtime. When returning from runtime we
can cause a lazy-deopt. The re-materialization of the unoptimized frame
works correct. Though the "v3" variable will contain a PC-relative
offset (telling the indirect goto how much to jump forward/backward in
the optimized code).
Obviously this PC-relative offset is specific to the optimized code.
When we continue in unoptimized code, the indirect goto has to jump a
different distance.
The fix this CL makes is to avoid calling the `InstanceCall([], ...)`
and instead encapsulate everything inside the IndirectGoto:
v1 <- InstanceCall([], ...)
IndirectGoto(v1 /*<- this is an index instead of an offset now*/)
This ensures in unoptimized code no deopt safepoint can happen between
looking up the offset in the constant offset array and the actual
indirect jump.
For the future: Maybe we should consider emitting a literal table at
the end of the instruction stream instead of using a
TypedDataInt32Array.
Issue https://github.com/dart-lang/sdk/issues/45213
Closes https://github.com/dart-lang/sdk/issues/46399
TEST=vm/dart{,_2}/deopt/indirect_goto_regress_46399_test
Change-Id: I81dc570ea997b3f477dd3f950a8fea03776eee0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204204
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This change adds can_be_sentinel() flag to CompileType and
prevents unboxing of phis which can be sentinel.
This flag means that set of values can potentially contain
Object::sentinel() which is used as a marker for the uninitialized
value of late variables.
TEST=runtime/tests/vm/dart/regress_46141_test.dart
Fixes https://github.com/dart-lang/sdk/issues/46141
Change-Id: I32f19488f54c6f69932584ecec3094e3b78cc0d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201600
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
If an IR instruction lazy-deopts it usually continues in unoptimized
code in the same IR instruction after-call.
Though in certain situations we want to continue before-call in
unoptimized code.
Two cases relevant in this CL:
* An instruction gets LICMed: If it lazy-deopts it will continue
at the Goto instruction outside the loop.
* A recognized method which got it's InstanceCall replaced by several
IR instructions. If any of them (except the last one) lazy-deopts
it should re-try the call in unoptimized code (e.g. []=)
In order to faciliate this we add a bit to the [Environment] which
encodes whether the continuation point in unoptimized code is
before-call - if so, we issue corresponding metadata.
Issue https://github.com/dart-lang/sdk/issues/45213
Issue https://github.com/dart-lang/sdk/issues/46070
TEST=runtime/tests/vm/dart{,_2}/regress_46070_test.dart
Change-Id: Ib824081768a2fd6293751a8fe09753e0d8155c87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200644
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Currently external data is counted twice on the receiver size: once for
received transferable, second for newly created external typed data.
Ensure new space is collected when allocating external at the limit.
TEST=SendReceiveBytesTransferable with verbose-gc
Change-Id: I129d913f89e098b5d3066ce249ac0c4702e1394d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199842
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
New invocation nodes have explicit functionType/resultType fields
which should be also visited by various visitors and transformers.
Without visiting those fields not all types are processed by
certain transformation (e.g. tree shaker) which causes crashes
during AOT compilation if new invocation nodes are enabled.
TEST=runtime/tests/vm/dart/regress_45966_test.dart (with new
invocation nodes).
Fixes https://github.com/dart-lang/sdk/issues/45966
Change-Id: I61d79650984a353d842b58da082a021ab37ab777
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199365
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
When TTSs access type argument vectors we should avoid using
Address/FieldAddress - which only work if offsets are guaranteed to be
within certain instruction encoding limits.
It also fixes Assembler::LoadCompressedFieldFromOffset on ARM64
to not assume (base, offset) is instruction encode-able.
TEST=vm/dart{,_2}/flutter_regress_82278_2_test
Change-Id: I9be316a068f222a6c1897c323111c4b18adb1e7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200222
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Martin Kustermann