Inner functions which called eval, and were the kind of functions
that can use `super`, were erroneously not marked as "uses_super_property",
leading to downstream crashes when the runtime tried to load the
[[HomeObject]] from them.
This patch eliminates the public Scope::uses_super_property()
API and ensures that callers always call Scope::NeedsHomeObject()
instead.
This is a minimal fix designed for easy merging; it's likely that
in the long run we should remove most mentions of "uses super property"
and replace them with "needs home object" for clarity.
Bug: v8:5516, chromium:774994
Change-Id: Id269dd33e35bd40f6b59a3d3e19330687afa64f8
Reviewed-on: https://chromium-review.googlesource.com/721879
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48619}
This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/715118.
The UI doesn't allow me to reland this automatically due to merge conflicts
so I ended up doing this manually.
Change-Id: Ic013b61f459cb1e91e24203fb31ae7c14f3754f8
Reviewed-on: https://chromium-review.googlesource.com/720136
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#48606}
Pause sweeper tasks when entering the Scavenger. In future CLs this
enables removing the page lock for the Scavenger.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Bug: v8:6923, chromium:774108
Change-Id: Idcb7e14b94704dead70c33a49e67047b88bb6c4c
Reviewed-on: https://chromium-review.googlesource.com/718200
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48603}
This is needed for proper deserialization of code and has the nice
side effect of fixing the nasty race condition that led us to
introducing a lock on the signature map.
R=mtrofin@chromium.orgCC=clemensh@chromium.org
Bug:
Change-Id: I6a018344ad8b58b088b20756d3b00ae08232bbb9
Reviewed-on: https://chromium-review.googlesource.com/718937
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48589}
With the introduction of the WasmContext, compiled code is no longer
specialized to the memory start and size (or recently, globals_start).
This CL uses the same WasmContext between the interpreter and compiled
code, removing the need for UpdateMemory() and cached instance info.
R=clemensh@chromium.org
Bug:
Change-Id: I0bd52352c9b6f3029246e94e239dc29f635e7920
Reviewed-on: https://chromium-review.googlesource.com/712734
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48584}
Also fix asan environment for testing on windows.
TBR=sergiyb@chromium.org
Bug: chromium:726584
Change-Id: Ic9e6afa714f4757ad1b0f2ebfa742e742e1c04b9
Reviewed-on: https://chromium-review.googlesource.com/720811
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48583}
This CL removes the code specialization for WASM functions that access
globals. Previously, we were embedding the start address of the globals
memory (globals_start) as a constant in the code, which required
patching for every instance. We now put this base in to the WasmContext,
which is available as a parameter to every WasmFunction.
R=ahaas@chromium.org,
CC=mtrofin@chromium.org
Bug:
Change-Id: I04bb739e898cc5a3b7dd081cc166483022d113fd
Reviewed-on: https://chromium-review.googlesource.com/712595
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48581}
New code should use nullptr instead of NULL.
This patch updates existing use of NULL to nullptr where applicable,
making the code base more consistent.
BUG=v8:6928,v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c
Reviewed-on: https://chromium-review.googlesource.com/718338
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48557}
This is a reland of 3d023952f2
Original change's description:
> [runtime] Make JSFunction::prototype_or_initial_map field optional.
>
> Functions that don't have prototype need to store neither prototype nor
> initial map, so the |prototype_or_initial_map| field is not required for
> such maps.
>
> Bug: v8:6459
> Change-Id: I4b3066bd6a4fed42c19f217bae82a8bce552bdca
> Reviewed-on: https://chromium-review.googlesource.com/570250
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46840}
Bug: v8:6459
Change-Id: I54e3516ea70474c6d4f873f7b91e74cb8a7d622a
Reviewed-on: https://chromium-review.googlesource.com/583307
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48523}
This flag describes that the memory defined in a wasm module has a
maximum size. Therefore I think kHasMaximumFlag is more appropriate.
R=titzer@chromium.org
Bug: v8:6921
Change-Id: Ie794d670f74e7f1f9a42822e2f774da85aaaaa4b
Reviewed-on: https://chromium-review.googlesource.com/718198
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48517}
When an immediate does not fit an add instruction we use a temporary register to
hold the value, using movw/movt to encode it. However, in order to remove a use
of r9 in TurboFan's code generator, we need to cope with no scratch registers
being available. That is to say that the destination and source registers are
the same, and `ip` is not available to use.
In this case, we can split an add instruction into a sequence of additions:
```
UseScratchRegisterScope temps(...);
Register my_scratch = temps.Acquire();
__ add(r0, r0, Operand(0xabcd); // add r0, r0, #0xcd
// add r0, r0, #0xab00
```
As a drive-by fix, make the disassembler test fail if we expected a different
number of instructions generated.
Bug: v8:6553
Change-Id: Ib7fcc765d28bccafe39257f47cd73f922c5873bf
Reviewed-on: https://chromium-review.googlesource.com/685014
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48491}
In the current implementation of hash code for objects (identity hash),
we do not bother to shift the hash when we retrieve it from the
hash-length bitfield in a property array. (Even worse, we store shifted
value even if we do not have property array or inside dictionaries.)
That means that the hash-code for objects is always divisible by 1024.
Since our hash table uses a simple masking with (2^logsize - 1) to
obtain the bucket, we get terrible hash collisions - essentially, our
hash table degenerates to a linked list for fewer than 1024 elements.
This CL always shifts the hash code so that the value in the lowest
21 bits is uniformly distributed.
This results in big improvements on medium to large hash tables.
A program storing 1M elements into a WeakMap gets roughly
17x faster. A program retrieving 1M elements from a Map
improves even more dramatically (>100x).
const a = [];
for (let i = 0; i < 1e6; i++) a[i] = {};
const m = new Map();
console.time("Map.set");
for (let i = 0; i < 1e6; i++) {
m.set(a[i], i);
}
console.timeEnd("Map.set");
console.time("Map.get");
let s = 0;
for (let i = 0; i < 1e6; i++) {
s += m.get(a[i]);
}
console.timeEnd("Map.get");
const w = new WeakMap();
console.time("WeakMap.set");
for (let i = 0; i < 1e6; i++) {
w.set(a[i], i);
}
console.timeEnd("WeakMap.set");
Before the fix:
Map.set: 157.575000
Map.get: 28333.182000
WeakMap.set: 6923.826000
After the fix:
Map.set: 178.382000
Map.get: 185.930000
WeakMap.set: 409.529000
Note that Map does not suffer from the hash collision on insertion because
it uses chaining (insertion into linked list is fast regardless of size!), and
we cleverly avoid lookup in the hash table on update if the key does not have
identity hash yet. This is in contrast to the WeakMap, which uses
open-addressing, and deals with collisions on insertion.
Bug: v8:6916
Change-Id: Ic5497bd4501e3b767b3f4acb7efb4784cbb3a2e4
Reviewed-on: https://chromium-review.googlesource.com/713616
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48480}
and add the implementations for BitwiseNot, Increment, Decrement.
This CL teaches the respective bytecode handlers about BigInts,
and collects kBigInt type feedback for them (which TF discards
for now, substituting "any").
Bug: v8:6791
Change-Id: I4e802b301b9702d8270bda400edd7e885e6b11b9
Reviewed-on: https://chromium-review.googlesource.com/706101
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48479}
This is a reland of ed6f00fb8e
Original change's description:
> [modules] Implement import.meta proposal
>
> Rewrites references to import.meta to a new GetImportMetaObject runtime
> call. Embedders can define a callback for creating the meta object using
> v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
> provided, an empty object with null prototype is created.
>
> This adds an example implementation to d8 that sets meta.url.
>
> Bug: v8:6693
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
> Reviewed-on: https://chromium-review.googlesource.com/707902
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48433}
TBR=adamk@chromium.org
Bug: v8:6693
Change-Id: Ie2d746ad996a56ed6ff50b832f320fe44e02f231
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/712834
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48468}
Only change over original: Init sig_index to 0 at
function-body-decoder-impl.h:168, to make MSAN happy on error path.
R=titzer@chromium.org
Change-Id: I9ac17215360523b656b10d2466201001b65992c0
Reviewed-on: https://chromium-review.googlesource.com/712655
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48463}
This patch is a first step towards target independent tests for the
CodeGenerator's AssembleMove and AssembleSwap methods.
The tests on top of which this builds would only make sure that no assertions
were triggered while generating moves, and that the hardware is happy executing
them. We want to do more and check that the generated code performs correctly.
In a nutshell, this introduces a facility that can do the following:
- Setup an environment with registers and stack slots initialised with random
values.
- Perform a list of randomly generated moves and/or swaps on those.
- Return the resulting environment.
This is a first step and therefore is lacking a few things which will be
implemented as follow-ups:
- Support for kSimd128 moves and swaps.
- Support large offsets for stack moves, as well as positive and negative.
- Compare the resulting environment against the result of a reference
simulation.
For more background information, see this design document:
https://docs.google.com/document/d/1KpioxCmtiB_9RaPaRidZPVtKlZ2BaNKGPYUjKFihhK0
Bug: v8:6848
Change-Id: Ie7dc837f4444df010ab58c64b722d40ee5d2af72
Reviewed-on: https://chromium-review.googlesource.com/677398
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48459}
This is a reland of 7c80f9ce69 with fixed restore
of system stack pointer in the tests.
Original change's description:
> Abstract some stack slot copies through a macro assembler function. This
> eliminates some non-paired stack operations.
>
> This is a reland of 1cc93be0f1 with
> additional tests, originally reviewed on
> https://chromium-review.googlesource.com/685238 and reverted due to an
> unrelated intermittent x64 failure.
>
> Bug: v8:6644
> Change-Id: If22b359dbda4bab1cb83cd8c44a2af5801012c37
> Reviewed-on: https://chromium-review.googlesource.com/707247
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/master@{#48419}
Bug: v8:6644
Change-Id: Ie8b45c73acc13df36c978a9ae4bee77082cb7c8d
Reviewed-on: https://chromium-review.googlesource.com/709515
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#48449}
This introduces a ToNumeric conversion to the runtime and interpreter.
ToNumeric behaves like ToNumber, except that it also lets BigInts pass.
Bug: v8:6791
Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7
Reviewed-on: https://chromium-review.googlesource.com/707013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48440}
When starting profiling, we iterate the heap to find all existing code
objects and the associated functions.
The iteration tried to log the function's code if either the closure's
code was optimized-but-not-deoptimized or if the optimized code in its
feedback vector was optimized-but-not-deoptimized.
That caused some trouble if the function's code was deoptimized but
we had a valid optimized code in the feedback vector. In that case
we would log the deoptimized code object from the closure, which
would later crash when trying to access the deoptimization information
(which we clear on deoptimization).
This CL just fixes the iteration so that we do not crash. A better fix
might be to log the function's code object if not deoptimized *and*
the code object in type feedback vector if not not deoptimized. Or
perhaps iterate optimized code objects and log those that have
deoptimization information.
Bug: chromium:763073
Change-Id: Iddee6a1c8b0fe332186ef7af2f3751c8828434b1
Reviewed-on: https://chromium-review.googlesource.com/709116
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48437}
This reverts commit ed6f00fb8e.
Reason for revert: tree is broken
NOTRY=true
NOTREECHECKS=true
Original change's description:
> [modules] Implement import.meta proposal
>
> Rewrites references to import.meta to a new GetImportMetaObject runtime
> call. Embedders can define a callback for creating the meta object using
> v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
> provided, an empty object with null prototype is created.
>
> This adds an example implementation to d8 that sets meta.url.
>
> Bug: v8:6693
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
> Reviewed-on: https://chromium-review.googlesource.com/707902
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48433}
TBR=adamk@chromium.org,gsathya@chromium.org,jan.krems@groupon.com
Change-Id: I908a508d5db84cc8ae60d4fd4a0446bb570c1492
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6693
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/710760
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48434}
Rewrites references to import.meta to a new GetImportMetaObject runtime
call. Embedders can define a callback for creating the meta object using
v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
provided, an empty object with null prototype is created.
This adds an example implementation to d8 that sets meta.url.
Bug: v8:6693
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
Reviewed-on: https://chromium-review.googlesource.com/707902
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48433}
The specced semantics of GetSubstitution are expected to change in the
case of malformed named references, or named references to nonexistent
named groups. The former will evaluate to the identity replacement of
'$<', while the latter will result in replacement by the empty string.
See also:
https://github.com/tc39/proposal-regexp-named-groups/issues/29
Bug: v8:5437, v8:6912
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I879288f775774cb0ec563f9d9129a99710efb77c
Reviewed-on: https://chromium-review.googlesource.com/708654
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48426}
When hitting objects that are allocated in the most recent lienar
allocation area, the concurrent marker currently has to bail out to the
main thread.
However, we only have to delay processing those objects until we are at
a safepoint, e.g. IM::Step(). With this change we flush those
on-hold-objects back to the shared queue upon performing an incremental
marking step.
Bug: chromium:694255
Change-Id: I25647d0fc581a5c4de0346bc394dc51062f65f70
Reviewed-on: https://chromium-review.googlesource.com/707315
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48424}
This reverts commit 7c80f9ce69.
Reason for revert: arm64 msan failures: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/17455/steps/Check/logs/copy_slots_up
Original change's description:
> [arm64] Add slot copier to masm and use in builtins
>
> Abstract some stack slot copies through a macro assembler function. This
> eliminates some non-paired stack operations.
>
> This is a reland of 1cc93be0f1 with
> additional tests, originally reviewed on
> https://chromium-review.googlesource.com/685238 and reverted due to an
> unrelated intermittent x64 failure.
>
> Bug: v8:6644
> Change-Id: If22b359dbda4bab1cb83cd8c44a2af5801012c37
> Reviewed-on: https://chromium-review.googlesource.com/707247
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/master@{#48419}
TBR=rmcilroy@chromium.org,martyn.capewell@arm.com,bmeurer@chromium.org
Change-Id: I8a8aeff89b6995d5fffaab1f2e4e45f478c28bed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6644
Reviewed-on: https://chromium-review.googlesource.com/708814
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48420}
Abstract some stack slot copies through a macro assembler function. This
eliminates some non-paired stack operations.
This is a reland of 1cc93be0f1 with
additional tests, originally reviewed on
https://chromium-review.googlesource.com/685238 and reverted due to an
unrelated intermittent x64 failure.
Bug: v8:6644
Change-Id: If22b359dbda4bab1cb83cd8c44a2af5801012c37
Reviewed-on: https://chromium-review.googlesource.com/707247
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#48419}
This flag was originally added as a staging mechanism to let us land and test
guard regions without the full trap handler feature landing. Additionally, we
thought we might enable guard regions without trap handlers on some systems.
Trap handlers are now supported, and there's not a real compelling reason for
why we need guard regions without trap handlers. Keeping the separate flag leads
to confusion, since some code treats guard regions and trap handlers the same,
while other code treats them as independent.
Removing this flag and its associated special cases makes everything more
uniform and predictable.
R=gdeepti@chromium.org
Change-Id: Icebab91d1f1e0c55e7a35c75b880085d37fa14ae
Reviewed-on: https://chromium-review.googlesource.com/706570
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48411}
This ensures that platform is initialized before the isolate and
properly restores the previous platform at the end of the test.
Bug:
Change-Id: I2771b7538362c400c5ff61411222beb7d7e62b02
Reviewed-on: https://chromium-review.googlesource.com/707111
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48405}
Each concurrent marking task maintains task_state[i]->marked_bytes.
When a task finishes, its local counter is flushed into global
total_marked_bytes_ atomic counter.
Bug: chromium:694255
Change-Id: I629467385e80bf229e06a4231673ceb5ef8e4aea
Reviewed-on: https://chromium-review.googlesource.com/704823
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48374}
