- 07 Nov, 2017 1 commit
-
-
cjihrig authored
This commit updates the jobs for generating postmortem metadata. I96a8a7cdded6f7c37b6f1da659d63df9e3a5de2b moved the Code class to a new file without updating the postmortem jobs. This resulted in some constants used by Node.js to disappear, leading to build failures on SmartOS. See: https://github.com/nodejs/node-v8/issues/21 Bug: Change-Id: Icf5f59fe464d933c4f5a3f622b08c01bc43c6a80 Reviewed-on: https://chromium-review.googlesource.com/741919 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#49168}
-
- 31 Oct, 2017 2 commits
-
-
Adam Klein authored
This reverts commit 521fa16e. Reason for revert: fails tests under code-serializer: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/17691 Original change's description: > [runtime] Slightly optimize creation of class literals. > > TBR=bmeurer@chromium.org > > Bug: v8:5799 > Change-Id: I61de5f8b3333db174dadf76ed983950acb39742b > Reviewed-on: https://chromium-review.googlesource.com/649509 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49044} TBR=rmcilroy@chromium.org,yangguo@chromium.org,mythria@chromium.org,gsathya@chromium.org,ishell@chromium.org,verwaest@chromium.org Change-Id: I994edb855a8a0aa6e7e7476b0b013a46aac6f2e7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5799 Reviewed-on: https://chromium-review.googlesource.com/745581Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49046}
-
Igor Sheludko authored
TBR=bmeurer@chromium.org Bug: v8:5799 Change-Id: I61de5f8b3333db174dadf76ed983950acb39742b Reviewed-on: https://chromium-review.googlesource.com/649509 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#49044}
-
- 26 Oct, 2017 1 commit
-
-
jgruber authored
This is the first step towards lazy-deserializing bytecode handlers. Bytecode handler code objects are now serialized into the builtins snapshot area (which, like many other related concepts, has become somewhat of a misnomer now that it contains both builtins and handlers). Handlers are still eagerly-deserialized upon Isolate creation. This will change in follow-up CLs. Bug: v8:6624 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I7b257f76f5e9e90d5f7b183980bae7bc621171fc Reviewed-on: https://chromium-review.googlesource.com/738030 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#48977}
-
- 25 Oct, 2017 1 commit
-
-
Anisha Rohra authored
Port 266e803e Original Commit Message: This CL adds a first implementation of Liftoff, the new wasm baseline compiler, for x64 and ia32. It currently supports the most important i32 instructions and control instructions. Whenever it encounters an instruction it does not support yet, it aborts. In a subsequent CL, Liftoff will be called from the WasmCompilationUnit, falling back to Turbofan compilation if the baseline compiler bails out. R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, clemensh@chromium.org, titzer@chromium.org BUG= LOG=N Change-Id: I35ad2b0230c37f523e24aa90b637a67e5ce59083 Reviewed-on: https://chromium-review.googlesource.com/735784Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48935}
-
- 23 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
This CL adds a first implementation of Liftoff, the new wasm baseline compiler, for x64 and ia32. It currently supports the most important i32 instructions and control instructions. Whenever it encounters an instruction it does not support yet, it aborts. In a subsequent CL, Liftoff will be called from the WasmCompilationUnit, falling back to Turbofan compilation if the baseline compiler bails out. R=titzer@chromium.org Bug: v8:6600 Change-Id: Ifa78fb9d546dce72c241ff01a251dfa13cb31c1d Reviewed-on: https://chromium-review.googlesource.com/716480 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48832}
-
- 20 Oct, 2017 1 commit
-
-
Michael Achenbach authored
This adds a wrapper script for run-tests.py that continues support for iterating over multiple modes and architectures. This also fixes a bug of the auto-detect target in gyp. Bug: chromium:772804 Change-Id: I61ff47b12e1925e010d822327a8aae8c402f435d Reviewed-on: https://chromium-review.googlesource.com/730225 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#48794}
-
- 19 Oct, 2017 5 commits
-
-
peterwmwong authored
- Add StringRaw CPP Builtin - Remove string.js Bug: v8:5049 Change-Id: I0d067c5b5aa9231383c2f9f2a9cf80f478fbbaa8 Reviewed-on: https://chromium-review.googlesource.com/727723Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48748}
-
Toon Verwaest authored
Bug: v8:6921 Change-Id: Id73a9ecc476c3c3ce0718bef81684787b72e366e Reviewed-on: https://chromium-review.googlesource.com/727202Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48733}
-
jgruber authored
Encapsulates special reservation / allocation behavior for builtin serialization. This allows us to remove special logic around kNextChunk in builtin deserialization (since we don't generate that bytecode anymore for builtins). Bug: v8:6624 Change-Id: Ice7673006cee53b9d11cdfb7f84d4175221c7984 Reviewed-on: https://chromium-review.googlesource.com/720357Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48725}
-
Michael Achenbach authored
Bug: v8:6917 Change-Id: Ia768c9aaf71e70d1376ae21a35fd539a7315b0cd Reviewed-on: https://chromium-review.googlesource.com/725802 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#48717}
-
Michael Achenbach authored
This ports the build_config json from GN to GYP to prepare deprecating tedious flags passing to the test runner. This also removes two unused GN flags that only hold temporary values. Bug: v8:6917 Change-Id: I976185f1541277dc5c9bfbaa7578f35c19dd254c Reviewed-on: https://chromium-review.googlesource.com/725706 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#48715}
-
- 18 Oct, 2017 1 commit
-
-
Jakob Gruber authored
This is a reland of 526c31d0 Original change's description: > Reland "[snapshot] Add BuiltinDeserializerAllocator" > > This is a reland of 2b9a6d89 > Original change's description: > > [snapshot] Add BuiltinDeserializerAllocator > > > > Encapsulates special reservation / allocation behavior for builtin > > deserialization. > > > > Bug: v8:6624 > > Change-Id: Ic784ed43b607c881b356c6e535c9dbe185e1d4cd > > Reviewed-on: https://chromium-review.googlesource.com/716229 > > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48638} > > TBR=yangguo@chromium.org > > Bug: v8:6624 > Change-Id: I07c49263b4ef128dfe9b97d364e9a279b343aa24 > Reviewed-on: https://chromium-review.googlesource.com/723520 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48647} TBR=yangguo@chromium.org Bug: v8:6624 Change-Id: I4186fcf89b9fce3433a02fc864346a300b90ffb5 Reviewed-on: https://chromium-review.googlesource.com/725439Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48666}
-
- 17 Oct, 2017 6 commits
-
-
Michael Achenbach authored
This reverts commit 526c31d0. Reason for revert: cfi still unhappy: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20cfi/builds/11905 Original change's description: > Reland "[snapshot] Add BuiltinDeserializerAllocator" > > This is a reland of 2b9a6d89 > Original change's description: > > [snapshot] Add BuiltinDeserializerAllocator > > > > Encapsulates special reservation / allocation behavior for builtin > > deserialization. > > > > Bug: v8:6624 > > Change-Id: Ic784ed43b607c881b356c6e535c9dbe185e1d4cd > > Reviewed-on: https://chromium-review.googlesource.com/716229 > > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48638} > > TBR=yangguo@chromium.org > > Bug: v8:6624 > Change-Id: I07c49263b4ef128dfe9b97d364e9a279b343aa24 > Reviewed-on: https://chromium-review.googlesource.com/723520 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48647} TBR=yangguo@chromium.org,jgruber@chromium.org Change-Id: I2a0534505d646a3ba90523f06f726b5059b90e35 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6624 Reviewed-on: https://chromium-review.googlesource.com/723521Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48650}
-
Jakob Gruber authored
This is a reland of 2b9a6d89 Original change's description: > [snapshot] Add BuiltinDeserializerAllocator > > Encapsulates special reservation / allocation behavior for builtin > deserialization. > > Bug: v8:6624 > Change-Id: Ic784ed43b607c881b356c6e535c9dbe185e1d4cd > Reviewed-on: https://chromium-review.googlesource.com/716229 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48638} TBR=yangguo@chromium.org Bug: v8:6624 Change-Id: I07c49263b4ef128dfe9b97d364e9a279b343aa24 Reviewed-on: https://chromium-review.googlesource.com/723520Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48647}
-
Michael Achenbach authored
This reverts commit 2b9a6d89. Reason for revert: Fails ubsan: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20UBSanVptr/builds/770 Original change's description: > [snapshot] Add BuiltinDeserializerAllocator > > Encapsulates special reservation / allocation behavior for builtin > deserialization. > > Bug: v8:6624 > Change-Id: Ic784ed43b607c881b356c6e535c9dbe185e1d4cd > Reviewed-on: https://chromium-review.googlesource.com/716229 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48638} TBR=yangguo@chromium.org,jgruber@chromium.org Change-Id: I0c6eceb88efe65526499e124acc4a45ee2904c1c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6624 Reviewed-on: https://chromium-review.googlesource.com/723141Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48641}
-
jgruber authored
Encapsulates special reservation / allocation behavior for builtin deserialization. Bug: v8:6624 Change-Id: Ic784ed43b607c881b356c6e535c9dbe185e1d4cd Reviewed-on: https://chromium-review.googlesource.com/716229 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48638}
-
jgruber authored
A continuation of the work in 59e4b751, this extracts logic around memory reservation and allocations out of the Deserializer class. Follow-up work is planned to create a specialized allocator for builtin deserialization. Bug: v8:6624 Change-Id: I7081cdc557ab8fb2571aadb816399e136ea2cdbb Reviewed-on: https://chromium-review.googlesource.com/716036 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48634}
-
Marja Hölttä authored
BUG=v8:5402,v8:6921 Change-Id: Iab2509554718a6beca73217f80cafedf650bd066 Reviewed-on: https://chromium-review.googlesource.com/718741Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48629}
-
- 16 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
Port the baseline version of Reflect.has to the CodeStubAssembler and reuse the existing logic for HasProperty (i.e. the HasProperty builtin). Also inline the Reflect.has builtin into TurboFan, by adding a check on the target in front of a use of the JSHasProperty operator. Technically this additional check is not necessary, because the JSHasProperty operator already throws if the target is not a JSReceiver, but the exception message is confusing then. This improves the performance of the micro-benchmark from reflectHasPresent: 337 ms. reflectHasAbsent: 472 ms. to reflectHasPresent: 121 ms. reflectHasAbsent: 216 ms. which is a nice 2.8x improvement in the best case. It also improves the chai test on the web-tooling-benchmark by around 1-2%, which is roughly the expected win (since Reflect.has overall accounts for around 3-4%). Bug: v8:5996, v8:6936, v8:6937 Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a Reviewed-on: https://chromium-review.googlesource.com/720959 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48608}
-
- 13 Oct, 2017 3 commits
-
-
Marja Hölttä authored
BUG=v8:5402,v8:6921 Change-Id: I96a8a7cdded6f7c37b6f1da659d63df9e3a5de2b Reviewed-on: https://chromium-review.googlesource.com/718342 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48552}
-
Toon Verwaest authored
Bug: v8:6921 Change-Id: I9e42d0a5e7ce7fdda1d00468a82d35b973200e2c Reviewed-on: https://chromium-review.googlesource.com/718697Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48545}
-
Marja Hölttä authored
This file was somehow inexplicably not moved when other parsing files were. BUG=v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iea92c61f83dbb5a8688c404ba87d35fa58e749b9 Reviewed-on: https://chromium-review.googlesource.com/718197 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48522}
-
- 12 Oct, 2017 1 commit
-
-
Michael Starzinger authored
This makes all inline allocation constructions go through the existing {AllocationBuilder} helper class. It hence ensures there is a single place for all sanity checking and and makes use-sites easier to read. R=jarin@chromium.org Change-Id: Ib5daf48acd93c631fccdfa095eda1afda7048115 Reviewed-on: https://chromium-review.googlesource.com/709056 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48502}
-
- 10 Oct, 2017 1 commit
-
-
Yang Guo authored
Bug: v8:6867 TBR=ofrobots@google.com Change-Id: I0eaebe04863f4cc9152655fedbeb67225a4d8103 Reviewed-on: https://chromium-review.googlesource.com/691722Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48422}
-
- 02 Oct, 2017 2 commits
-
-
Ben L. Titzer authored
R=gdeepti@chromium.org Bug: Change-Id: Ic2e519d24354b3327a92daa0d4d6e06c9ca4605e Reviewed-on: https://chromium-review.googlesource.com/687056 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48256}
-
Clemens Hammacher authored
With --wasm-trace-memory, both compiled code and the interpreter will output each memory load or store. This helps to debug miscompilations in emscripten or in V8, like the referenced bug. R=titzer@chromium.org Bug: chromium:718858 Change-Id: I90704d164975b11c65677f86947ab102242d5153 Reviewed-on: https://chromium-review.googlesource.com/684316Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48255}
-
- 28 Sep, 2017 3 commits
-
-
Toon Verwaest authored
There are only very few custom compiled IC handlers left that go in there, and for each compiled handler we only have 1 cache hit on top25; maximally saving 60ms over 33s. Additionally we'll migrate the remaining handlers to data-driven handlers anyway. Let's try to remove this code. Bug: Change-Id: Ib874cc498015046a3ff67c83ea8b10b3c4eb7d0f Reviewed-on: https://chromium-review.googlesource.com/668409 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48201}
-
Peter Marshall authored
ZoneList still used List as a base class, so this CL merges the two classes together. We also remove unused functions in List and ZoneList. We keep the inline header but move it to src/zone/zone-list-inl.h. The includes that use this header are still quite tangled, but we can fix that later. Bug: v8:6333 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ia809813834b2328ff616623f8a843812a1eb42a7 Reviewed-on: https://chromium-review.googlesource.com/681658 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48200}
-
Peter Marshall authored
The members of HandleScopeImplementer are copied with memcpy when the isolate is transferred to another thread. List contained some primitives which allowed us to manually free the backing store, which was needed in order to ensure that threads would not hold on to old pointers and use them later. With std::vector, we can't do that. Here we change the HandleScopeImplementer to instead use a custom structure DetachableVector, which contains a std::vector but allows manual detaching and freeing of the backing store. This allows us to maintain the old behavior. Bug: v8:6333 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0 Reviewed-on: https://chromium-review.googlesource.com/660125Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#48197}
-
- 25 Sep, 2017 1 commit
-
-
Maya Lekova authored
Bug: Change-Id: I7cb8ace4183c0dcf34d71d1b378204383c17ba56 Reviewed-on: https://chromium-review.googlesource.com/678718Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Maya Lekova <mslekova@google.com> Cr-Commit-Position: refs/heads/master@{#48133}
-
- 22 Sep, 2017 1 commit
-
-
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}
-
- 20 Sep, 2017 1 commit
-
-
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:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#48094}
-
- 19 Sep, 2017 2 commits
-
-
Michael Lippautz authored
Removes - SequentialMarkingDeque - The ability to handle marking deque overflow - BlackToGrey transitions We switched to a different marking work list on M61 that fails in OOM upon failing to allocate Segments used in the work list. Bug: chromium:758570 Change-Id: I66e2ab912271bf84b085dccc9b4bdd96076b64fb Reviewed-on: https://chromium-review.googlesource.com/632676 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#48078}
-
Jakob Gruber authored
This CL refactors allocation & reservation logic into a new DefaultSerializerAllocator class. In upcoming work, this will be further extended by a custom allocator for builtin serialization. Additionally, this cleans up a bunch of cosmetics (encapsulation and other nits). Bug: v8:6624 Change-Id: Ibcf12a525c8fcb26d9c16b7a12fd598c37a0e10a Reviewed-on: https://chromium-review.googlesource.com/650357Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48077}
-
- 16 Sep, 2017 3 commits
-
-
Mircea Trofin authored
This reverts commit ee5c31f3. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
-
Mircea Trofin authored
This reverts commit 110d9ab0. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? Original change's description: > [wasm] A simple allocator datastructure for off-the heap > > We'll use this allocator in a follow-up CL to: > - allocate speculative sizes of memory for a module that's being > compiled (e.g. 2*size of wasm code). > - each module will own such a sub-pool, and then use it to allocate > contiguous chunks of memory for code. > > The underlying assumptions for the chosen allocation strategy is that: > - the allocation granularity for pools is 1 page, so that no one page > is owned by more than one wasm module > - typical pool sizes (given module sizes) are multiple pages. > - modules and module instances are typically few and long lived. Typically, > we expect one module and one instance. > > This means we shouldn't expect fragmentations that lead to code being > non-allocatable, or prohibitively many ranges. > > The data structure just manages ranges of addresses. Virtual memory management > will be separate, as part of the responsibility of a "WasmHeap" > that will be introduced in the future. So will concurrency control. > > Bug: > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > Reviewed-on: https://chromium-review.googlesource.com/669296 > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Reviewed-by: Eric Holk <eholk@chromium.org> > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48053} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670141Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48054}
-
Mircea Trofin authored
We'll use this allocator in a follow-up CL to: - allocate speculative sizes of memory for a module that's being compiled (e.g. 2*size of wasm code). - each module will own such a sub-pool, and then use it to allocate contiguous chunks of memory for code. The underlying assumptions for the chosen allocation strategy is that: - the allocation granularity for pools is 1 page, so that no one page is owned by more than one wasm module - typical pool sizes (given module sizes) are multiple pages. - modules and module instances are typically few and long lived. Typically, we expect one module and one instance. This means we shouldn't expect fragmentations that lead to code being non-allocatable, or prohibitively many ranges. The data structure just manages ranges of addresses. Virtual memory management will be separate, as part of the responsibility of a "WasmHeap" that will be introduced in the future. So will concurrency control. Bug: Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 Reviewed-on: https://chromium-review.googlesource.com/669296 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Eric Holk <eholk@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#48053}
-
- 13 Sep, 2017 1 commit
-
-
Mostyn Bramley-Moore authored
Previously instructions-arm64.h was alternatively defining or declaring some constants based on whether or not ARM64_DEFINE_FP_STATICS was defined, and it was assumed that exactly one file would include this header with the macro defined. In jumbo builds, the header guards in instructions-arm64.h meant that the resulting state of the header file would be whichever of the two cases that appeared first in the compilation unit. This would cause multiple definitions in some cases and no definitions in some other cases (or if you were really lucky, it would work out ok). Let's move these constants to a separate source file temporarily, to be excluded from jumbo compilation units. This code should eventually be replaced with a cleaner solution. Bug: chromium:746958 Change-Id: I7edb1821ef408afd50c6b236d63d3c07f955b58f Reviewed-on: https://chromium-review.googlesource.com/663898 Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48003}
-
- 11 Sep, 2017 1 commit
-
-
Georg Neis authored
BigInt is a new primitive type of arbitrary precision integers, proposed in https://tc39.github.io/proposal-bigint. This CL introduces a corresponding instance type, map, and C++ class to V8 and adds BigInt support to a few operations (see the test file). Much more is to come. Also, the concrete representation of BigInts is not yet fixed, currently a BigInt is simply a wrapped Smi. Bug: v8:6791 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45 Reviewed-on: https://chromium-review.googlesource.com/657022Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47956}
-