Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=ulan@chromium.org
Bug: v8:6837
Change-Id: I8d900f3c703dea6ee3bcc225a1d2754e91666b9d
Reviewed-on: https://chromium-review.googlesource.com/671047
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48136}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=jarin@chromium.org
Bug: v8:6837
Change-Id: I712580c2a4326e06ee3d6d0eb4ff8c7d24f5fdb9
Reviewed-on: https://chromium-review.googlesource.com/671227
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48135}
Track whether the async arrow func parameter list was simple or not; the
information is already there, we just didn't pipe it through correctly. It's
needed by PreParser so that it can create the correct Scope structure.
Implementation notes:
- I could've used async_classifier for transmitting the "is_simple" bit, but I
made it explicit (it would be unnecessary to use ExpressionClassifier for
this, as we're not classifying any expressions) instead.
- I'm also moving work (setting parameter_list.is_simple) from Parser to
ParserBase, and adding a DCHECK in Parser to assert that the work was indeed
already done.
BUG=v8:5516,chromium:765532
Change-Id: Iacf91b150d1b57996544b5e64baa7d91ac134445
Reviewed-on: https://chromium-review.googlesource.com/674695
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48132}
We can constant-fold JSLoadProperty(o, i) when o is a known object (i.e.
TurboFan's context specialization provides a known non-null/-undefined
constant value for it), i is a known array index and o["i"] is an
element on the receiver, that is non-configurable and non-writable (i.e.
o was frozen using Object.freeze earlier, or o is a String object).
This significantly reduces execution time of the tagged templates
micro-benchmarks (ES6 and Babel transpiled), when combined with the
CL https://chromium-review.googlesource.com/c/v8/v8/+/677462, it goes
from
templateStringTagES5: 4552 ms.
templateStringTagES6: 14185 ms.
templateStringTagBabel: 7626 ms.
to
templateStringTagES5: 4550 ms.
templateStringTagES6: 616 ms.
templateStringTagBabel: 589 ms.
so overall a solid 23x improvement on the ES6 benchmark. This is
representative of the six-speed-templatestringtag-es6 benchmark.
Bug: v8:6819, v8:6820, v8:6831
Change-Id: Ia45fbdf92977bfbe7400cfa60bd362b78086dc26
Reviewed-on: https://chromium-review.googlesource.com/677603
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48131}
This patch ensures that the concurrent marking tasks do not
use more than the half of the available background threads.
Bug: chromium:694255
Change-Id: I67d6eb3e717945f777d0711bd094630573c78661
Reviewed-on: https://chromium-review.googlesource.com/678636
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48130}
Casting to HeapObject before checking whether the object actually is
a HeapObject is undefined behavior.
Bug: chromium:738743
Change-Id: I7be8dfbc18203c6be008af73549a915f9b6bd3de
Reviewed-on: https://chromium-review.googlesource.com/680768
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48128}
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).
This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.
With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from
templateStringTagES5: 4552 ms.
templateStringTagES6: 14185 ms.
templateStringTagBabel: 7626 ms.
to
templateStringTagES5: 4515 ms.
templateStringTagES6: 7491 ms.
templateStringTagBabel: 7639 ms.
which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.
Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
Fixes the collection of V8.WasmFuncctionSizeBytes.wasm for UMA stats.
Bug: v8:6852
Change-Id: Ib25d249dd2856ffb8a3205e54ba052c1bc9a09cf
Reviewed-on: https://chromium-review.googlesource.com/678448
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48125}
- Moves GetRandomMmapAddr from platform to v8::internal allocation
primitives, in preparation for delegating this to the embedder.
- Adds hint parameters to OS functions that used to use this function.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iad72e6eac9c08a3e22c2cd2b2905623b8e514ae0
Reviewed-on: https://chromium-review.googlesource.com/677777
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48124}
TurboAssembler::CallRecordWriteStub contains info that could be used to
conditionally skip generational write barrier or skip saving float-point
registers. This commits uses those info in RecordWrite stub.
Bug: chromium:749486
Change-Id: I41c9a593473e1f8863a09887fd2ce917f1d4fb3b
Reviewed-on: https://chromium-review.googlesource.com/672527
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48123}
Add padding for the interpreter registers when needed, to make the
interpreter frame a multiple of 16 bytes. The padding needs to be added
in the InterpreterEntryTrampoline and when generating an interpreter
frame in the deoptimizer. It also needs to be considered when
calculating the size of the interpreter frame during OSR and stack
unwinding.
Bug: v8:6644
Change-Id: Icfec94079cf0785fc8a2506ff555b5f9e89e3d13
Reviewed-on: https://chromium-review.googlesource.com/664563
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48121}
This changes CPU check to use 'target_cpu' instead of 'v8_target_cpu'.
Bug: chromium:694255
Change-Id: Ic3ad5253e4e0b66b13e9f16a5842bcf49881fa52
Reviewed-on: https://chromium-review.googlesource.com/677994
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48119}
This change enables moving the WasmToJSWrapper off the GCed heap
R=bradnelson@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
Bug:
Change-Id: I1ea8810fa7b71bcb2a80a1390742db64872c5bb1
Reviewed-on: https://chromium-review.googlesource.com/665977
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48118}
The code after the binary-search loop is unlikely to be reached,
but not actually UNREACHABLE(). Restore the "return 0" that was
there until a cleanup [1] removed it.
[1] crrev.com/c/507287/2/src/date.cc
Bug: chromium:767039
Change-Id: I9e007d3b7d693d4866ccc3e3cf2b71e78e9bd07f
Reviewed-on: https://chromium-review.googlesource.com/675755
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48117}
This is mainly about clarifying the frame contents for each call type, though
assertions on the even length of Push/PopRegList() are also added.
Bug: v8:6644
Change-Id: I4dfe6ac2603e2bab895758e85d8dfe06770d8987
Reviewed-on: https://chromium-review.googlesource.com/672844
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#48116}
This is a reland of c6b153fd69
Original change's description:
> [cctest] Add fuzz tests for generating parallel moves.
>
> These new tests are somewhat similar to the existing gap resolver tests except
> we use the code generator and eventually run the generated code. The main idea
> is to cover cases that are difficult to hit, such as move from/to slots which
> are out of range of loads and stores, but may happen nonetheless.
>
> At this time, the tests only make sure the code generator actually generated
> some code, and that this code runs. In the future, it would be great to also
> check that the moves were actually performed.
>
> Bug: v8:6553
> Change-Id: I089a25fa05b3a20649658bb8952926ab11f91d68
> Reviewed-on: https://chromium-review.googlesource.com/574850
> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47733}
Bug: v8:6553
Change-Id: Ia3eac9d7e6a23e2f6fea839b71d460cb7ad6ff6e
Reviewed-on: https://chromium-review.googlesource.com/645868
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48115}
- Changes encoding movups to one where destination is the first operand.
Bug: v8:6843
Change-Id: Ie2f957403aa75b5490446b43e37c064e8055693f
Reviewed-on: https://chromium-review.googlesource.com/676134
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48114}
This is a reland of f2cd10db14
Original change's description:
> Reland "[Memory] Move VirtualMemory out of base:: platform."
>
> This is a reland of 4dd293d922
> Original change's description:
> > [Memory] Move VirtualMemory out of base:: platform.
> >
> > - Moves base::VirtualMemory to v8::internal::VirtualMemory.
> > - Makes VirtualMemory platform-independent by moving internals to new
> > OS:: static methods, for each platform.
> >
> > This will make it easier to delegate memory management in VirtualMemory
> > to V8::Platform, so that embedders like Blink can override it. We can't
> > depend on V8::Platform in base/platform.
> >
> > Bug: chromium:756050
> > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> > Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
> > Reviewed-on: https://chromium-review.googlesource.com/653214
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48048}
>
> Bug: chromium:756050
> Change-Id: Ib492c7c69f1833be127a571808301e96b84b8aa2
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/671125
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48084}
Bug: chromium:756050
Change-Id: Ie596730b5cefc38137cab7fc1f76613f5af7b825
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/675283
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48113}
The baseline compiler needs to know the depth in order to access the
parent block. This is a small CL, but anything that can land before the
big baseline CL reduced the complexity of the latter.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I2e29cc974908438266adb4301026dfe5fbfb1990
Reviewed-on: https://chromium-review.googlesource.com/677301
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48112}
There are some mysterious, unreproducible CHECK failures (inconsistent
data). Add more information onto the stack (and thus, to minidumps) for
debugging them.
BUG=v8:5516,chromium:766693
Change-Id: Ic1ebc3036957ede4e3e1c1d287479897e54e40ed
Reviewed-on: https://chromium-review.googlesource.com/677294
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48111}
In the current implementation, compilation would fail because
operator<< is not defined for enum classes. For others, the compiler
finds more than one operator<<, so it fails because it's ambiguous.
This CL fixes this by printing the integer value for enums, uses the
operator<< for all values that support it, and prints "<unprintable>"
otherwise.
Also, lots of unit tests.
R=ishell@chromium.org
Bug: v8:6837
Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4
Reviewed-on: https://chromium-review.googlesource.com/671016
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48110}
And add some tests for (seemingly) previously uncovered cases.
The additional check for unreachable code is not needed any more, since
polymorphic stack values get assigned a specific type on their first
use or validation anyway. Hence the first entry in the br_table will
assign specific types to all polymorphic stack values, and type checking
will fail if later entries do not match.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7
Reviewed-on: https://chromium-review.googlesource.com/675405
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48109}
This fix is two-fold:
1) Incremental UTF-8 decoding: Unify incorrect UTF-8 handling between V8 and
Blink.
Incremental UTF-8 decoding used to allow some overlong sequences / invalid code
points which Blink treated as errors. This caused the decoder and the Blink
UTF-8 decoder to produce a different number of bytes, resulting in random
failures when scripts were streamed (especially, this was detected by the
skipping inner functions feature which adds CHECKs against expected function
positions).
2) Non-incremental UTF-8 decoding: return the correct amount of invalid characters.
According to the encoding spec ( https://encoding.spec.whatwg.org/#utf-8-decoder
), the first byte of an overlong sequence / invalid code point generates an
invalid character, and the rest of the bytes are not processed (i.e., pushed
back to the byte stream). When they're handled, they will look like lonely
continuation bytes, and will generate an invalid character each.
As a result, an overlong 4-byte sequence should generate 4 invalid characters
(not 1).
This is a potentially breaking change, since the (non-incremental) UTF-8
decoding is exposed via the API (String::NewFromUtf8). The behavioral difference
happens when the client is passing in invalid UTF-8 (containing overlong /
surrogate sequences).
However, afaict, this doesn't change the semantics of any JavaScript program:
according to the ECMAScript spec, the program is a sequence of Unicode code
points, and there's no way to invoke the UTF-8 decoding functionalities from
inside JavaScript. Though, this changes the behavior of d8 when decoding source
files which are invalid UTF-8.
This doesn't change anything related to URI decoding (it already throws
exceptions for overlong sequences / invalid code points).
BUG: chromium:765608, chromium:758236, v8:5516
Bug:
Change-Id: Ib029f6a8e87186794b092e4e8af32d01cee3ada0
Reviewed-on: https://chromium-review.googlesource.com/671020
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48105}
By adding a per test source file namespace, we can avoid a lot of
symbol collisions in jumbo builds.
While we're at it, let's remove some "using" statements that also
cause trouble.
Bug: chromium:746958
Change-Id: I6f8a723e1ba5905888638e0687b23193f3f012ca
Reviewed-on: https://chromium-review.googlesource.com/676803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48102}
Memory instantiate on initialize should always patch memory
references. If memory references are not patched for no initial
memory, on subsequent calls to grow_memory in wasm functions for
instances that share a module, the references will be patched
without resetting cloned compiled values to their correct initial
values.
BUG=chromium:763439
Change-Id: I666439332379b02aa344e99d61ef3dc88ab86cc8
Reviewed-on: https://chromium-review.googlesource.com/674707
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48097}
- Changes x64 AssembleSwap to push/pop to swap 128 bit slot swaps.
- Reorders instructions to simplify 32/64 bit FP slot swaps.
- Refactor ia32 version of this, eliminating OffsetOperand in favor of
existing ToOperand.
Bug: v8:6020
Change-Id: Ie0ae4c581c9aeb88ee786797851c3c77d5210a3d
Reviewed-on: https://chromium-review.googlesource.com/669748
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48096}
For consistency with surrounding handlified code. No change in
functionality intended.
Change-Id: I8501514ce9caf94fc7e6fb45162fcfd3d730efcd
Reviewed-on: https://chromium-review.googlesource.com/671671
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48095}
Along with BigInt.prototype. Their functions only have skeleton
implementations. The purpose of this change is to make it easier
to gradually increase test coverage (e.g. for toString(radix)).
Of course this is still behind the --harmony-bigint flag.
Bug: v8:6791
Change-Id: Ic307fd9165c56ac782fba18d648ce893daaa718f
Reviewed-on: https://chromium-review.googlesource.com/671209
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48094}
There is no support to emulate atomic WASM operations on big-endian
platforms, since this would require bit swapping as a part of atomic
operations. Therefore, cctest/test-run-wasm-atomics/* will be skipped.
TEST=cctest/test-run-wasm-atomics/*
BUG=
Change-Id: I1a8b085f816f615011788092e6fc8a8390678382
Reviewed-on: https://chromium-review.googlesource.com/671010
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48093}
Do this by deleting code after calls to V8_Fatal() (either through
UNREACHABLE() or FATAL()). Comments suggest that the returns there
were needed to make a compiler happy, but all compilers seem to be
happy with this change too. My guess is that either
https://codereview.chromium.org/1393023003 which marked V8_Fatal()
as noreturn, or https://chromium-review.googlesource.com/#/c/544845/
which switched to the C++11 spelling of noreturn, fixed the warnings
that the explicit code after V8_Fatal() was supposed to silence.
There's one more warning in src/compiler/machine-graph-verifier.cc,
but fixing that changes behavior. I asked about that one in
https://codereview.chromium.org/2573573004/#msg27 instead.
Bug: chromium:346399
Change-Id: Ie9519d5432bdeaaf382e8390d8254d3b79e622e4
Reviewed-on: https://chromium-review.googlesource.com/669803
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48092}
This fixes a few leftovers where we use WASM_EXEC_TEST, but then
unconditionally execute the compiled code, and also changes more tests
to use WASM_EXEC_TEST, hence run in both the interpreter and compiled
code.
Once we have land the baseline compiler, those tests will also execute
in baseline compilation mode.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I79598df21a7538934306e01ca6593f05afe19ed3
Reviewed-on: https://chromium-review.googlesource.com/672528
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48091}
This reverts commit f2cd10db14.
Reason for revert: Blocks the roll https://chromium-review.googlesource.com/c/chromium/src/+/674623
Original change's description:
> Reland "[Memory] Move VirtualMemory out of base:: platform."
>
> This is a reland of 4dd293d922
> Original change's description:
> > [Memory] Move VirtualMemory out of base:: platform.
> >
> > - Moves base::VirtualMemory to v8::internal::VirtualMemory.
> > - Makes VirtualMemory platform-independent by moving internals to new
> > OS:: static methods, for each platform.
> >
> > This will make it easier to delegate memory management in VirtualMemory
> > to V8::Platform, so that embedders like Blink can override it. We can't
> > depend on V8::Platform in base/platform.
> >
> > Bug: chromium:756050
> > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> > Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
> > Reviewed-on: https://chromium-review.googlesource.com/653214
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48048}
>
> Bug: chromium:756050
> Change-Id: Ib492c7c69f1833be127a571808301e96b84b8aa2
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/671125
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48084}
TBR=bbudge@chromium.org,ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org,scottmg@chromium.org
Change-Id: I04176d77ca9ad8315b0e1bb2b21f40f2c8ab9536
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/674843
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48088}
The work list should be empty in the case we are not tearing down
during incremental marking. Explicitly clear during incremental marking
and rely on DCHECKs for the other case.
Bug: chromium:758570
Change-Id: Iecc8935f0cbfda67f0e7afde42930050e7c94d2d
Reviewed-on: https://chromium-review.googlesource.com/674504
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48087}
