- 22 Sep, 2017 8 commits
-
-
Benedikt Meurer authored
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/677462Reviewed-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}
-
Karl Schimpf authored
Fixes the collection of V8.WasmFuncctionSizeBytes.wasm for UMA stats. Bug: v8:6852 Change-Id: Ib25d249dd2856ffb8a3205e54ba052c1bc9a09cf Reviewed-on: https://chromium-review.googlesource.com/678448Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Commit-Queue: Karl Schimpf <kschimpf@chromium.org> Cr-Commit-Position: refs/heads/master@{#48125}
-
Bill Budge authored
- 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/677777Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#48124}
-
Albert Mingkun Yang authored
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/672527Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com> Cr-Commit-Position: refs/heads/master@{#48123}
-
Mostyn Bramley-Moore authored
BUILD is already defined in test/cctest/wasm/wasm-run-utils.h. Bug: chromium:746958 Change-Id: Icf577ce91424d9851d2db39658fd52c68c864995 Reviewed-on: https://chromium-review.googlesource.com/676843Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Cr-Commit-Position: refs/heads/master@{#48122}
-
Georgia Kouveli authored
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:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48121}
-
Michael Lippautz authored
Bug: chromium:738865 Change-Id: I0b5dea276363aa5bf51eea0b7fde1f4f265a6360 Reviewed-on: https://chromium-review.googlesource.com/678354Reviewed-by:
-
Ulan Degenbaev authored
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/677994Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#48119}
-
- 21 Sep, 2017 21 commits
-
-
Aseem Garg authored
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/665977Reviewed-by:
-
Jakob Kummerow authored
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/675755Reviewed-by:
-
Martyn Capewell authored
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/672844Reviewed-by:
-
Pierre Langlois authored
This is a reland of c6b153fd 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/645868Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#48115}
-
Bill Budge authored
- Changes encoding movups to one where destination is the first operand. Bug: v8:6843 Change-Id: Ie2f957403aa75b5490446b43e37c064e8055693f Reviewed-on: https://chromium-review.googlesource.com/676134Reviewed-by:
-
Bill Budge authored
This is a reland of f2cd10db Original change's description: > Reland "[Memory] Move VirtualMemory out of base:: platform." > > This is a reland of 4dd293d9 > 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/675283Reviewed-by:
-
Clemens Hammacher authored
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/677301Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48112}
-
Marja Hölttä authored
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/677294Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48111}
-
Clemens Hammacher authored
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}
-
Clemens Hammacher authored
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.org CC=titzer@chromium.org Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7 Reviewed-on: https://chromium-review.googlesource.com/675405Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48109}
-
Ivica Bogosavljevic authored
Bug: Change-Id: Ia7bbbb2aba28ec36b470a1b23ebe38fc3a09e600 Reviewed-on: https://chromium-review.googlesource.com/657757 Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Reviewed-by:
Miran Karić <Miran.Karic@imgtec.com> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48108}
-
Ulan Degenbaev authored
This is a reland of 8c4a8250 Original change's description: > [heap] Enable concurrent marking for x86 and x64. > > Bug: chromium:694255 > Change-Id: I28c8c6e5ba6c84123f3951e822c132860cb22c1d > Reviewed-on: https://chromium-review.googlesource.com/641451 > Commit-Queue: Kentaro Hara <haraken@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Hannes Payer (slow) <hpayer@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48100} Bug: chromium:694255 TBR: mlippautz@chromium.org Change-Id: Ic36515dbd418c219bccbbf371126a4dfd66a466f Reviewed-on: https://chromium-review.googlesource.com/676966Reviewed-by:
-
Mostyn Bramley-Moore authored
Bug: chromium:746958 Change-Id: I0c1dfe1019b5324d322f5c7a6a2e6095c18f0b40 Reviewed-on: https://chromium-review.googlesource.com/676583Reviewed-by:
-
Marja Hölttä authored
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:
-
Michael Lippautz authored
No-Try: true Bug: v8:6845 Change-Id: Ic823fe62e0ee6a954ca704d37a6cb54473720b9c Reviewed-on: https://chromium-review.googlesource.com/676890 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This reverts commit 8c4a8250. Reason for revert: Flaky dcheck on several bots, e.g.: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/17055 Original change's description: > [heap] Enable concurrent marking for x86 and x64. > > Bug: chromium:694255 > Change-Id: I28c8c6e5ba6c84123f3951e822c132860cb22c1d > Reviewed-on: https://chromium-review.googlesource.com/641451 > Commit-Queue: Kentaro Hara <haraken@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Hannes Payer (slow) <hpayer@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48100} TBR=ulan@chromium.org,haraken@chromium.org,machenbach@chromium.org,hpayer@chromium.org,mlippautz@chromium.org Change-Id: Id5954676c75e69b66e85f05ffab737ab7f760101 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:694255 Reviewed-on: https://chromium-review.googlesource.com/677203Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48103}
-
Mostyn Bramley-Moore authored
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/676803Reviewed-by:
-
Igor Sheludko authored
Bug: chromium:346399 Change-Id: I4d93dbef6deb0fee477f88e20c40106868e99dee Reviewed-on: https://chromium-review.googlesource.com/674940Reviewed-by:
-
Ulan Degenbaev authored
Bug: chromium:694255 Change-Id: I28c8c6e5ba6c84123f3951e822c132860cb22c1d Reviewed-on: https://chromium-review.googlesource.com/641451 Commit-Queue: Kentaro Hara <haraken@chromium.org> Reviewed-by:
Hannes Payer (slow) <hpayer@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
Bug: v8:6791 Change-Id: If128758e92e566603fa1e3213f42e1dd7a246793 Reviewed-on: https://chromium-review.googlesource.com/674134 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#48099}
-
Ulan Degenbaev authored
This reverts commit ec952aaa. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=767144 Original change's description: > Reland "[profiler] proper observation of old space inline allocations" > > This is a reland of 672a41c3 > Original change's description: > > [profiler] proper observation of old space inline allocations > > > > Bug: chromium:633920 > > Change-Id: I9a2f4a89f6b9c0f63cb3b166b06a88a12f0a203c > > Reviewed-on: https://chromium-review.googlesource.com/631696 > > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48043} > > Bug: chromium:633920 > Change-Id: I6fe743d31b8ff26f3858488d4c014c62d3c85add > Reviewed-on: https://chromium-review.googlesource.com/671127 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> > Cr-Commit-Position: refs/heads/master@{#48085} TBR=ulan@chromium.org,mlippautz@chromium.org,ofrobots@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:633920 Change-Id: I576cdab4a03f9fe057ebe1bf7da9dfe3c7bf62cd Reviewed-on: https://chromium-review.googlesource.com/676683Reviewed-by:
-
- 20 Sep, 2017 11 commits
-
-
Deepti Gandluri authored
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/674707Reviewed-by:
-
Bill Budge authored
- 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:
-
Jakob Kummerow authored
For consistency with surrounding handlified code. No change in functionality intended. Change-Id: I8501514ce9caf94fc7e6fb45162fcfd3d730efcd Reviewed-on: https://chromium-review.googlesource.com/671671Reviewed-by:
-
Jakob Kummerow authored
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:
-
Ilija Pavlovic authored
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/671010Reviewed-by:
Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Reviewed-by:
-
Nico Weber authored
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/669803Reviewed-by:
-
Clemens Hammacher authored
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:
-
Ivo Markovic authored
Bug: Change-Id: I62414a59246af359634b1309b03216c0a5c8764b Reviewed-on: https://chromium-review.googlesource.com/663728Reviewed-by:
-
Michael Lippautz authored
Bug: chromium:758570 Change-Id: Ia2bd72c1756fbc4062c62d975e25bb0ca209a6ad Reviewed-on: https://chromium-review.googlesource.com/674465Reviewed-by:
-
Michael Hablich authored
This reverts commit f2cd10db. 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 4dd293d9 > 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/674843Reviewed-by:
Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#48088}
-
Michael Lippautz authored
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/674504Reviewed-by:
-
