- 13 Oct, 2017 1 commit
-
-
Igor Sheludko authored
This is a reland of 3d023952 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/583307Reviewed-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}
-
- 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}
-
- 05 Sep, 2017 1 commit
-
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24 TBR: mstarzinger@chromium.org Reviewed-on: https://chromium-review.googlesource.com/647596 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47808}
-
- 04 Sep, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit 84c2dfce. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876 Original change's description: > Remove weak-list of optimized JS functions. > > This CL removes the weak-list of JS functions from the context > and all the code that iterares over it. This list was being used > mainly during deoptimization (for code unlinking) and during > garbage collection. Removing it will improve performance of > programs that create many closures and trigger many scavenge GC > cycles. > > No extra work is required during garbage collection. However, > given that we no longer unlink code from JS functions during > deoptimization, we leave it as it is, and on its next activation > we check whether the mark_for_deoptimization bit of that code is > set, and if it is, than we unlink it and jump to lazy compiled > code. This check happens in the prologue of every code object. > > We needed to change/remove the cctests that used to check > something on this list. > > Working in x64, ia32, arm64, arm, mips64 and mips. > > Bug: v8:6637 > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 > Reviewed-on: https://chromium-review.googlesource.com/600427 > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47790} TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6637 Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47792}
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 Reviewed-on: https://chromium-review.googlesource.com/600427 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47790}
-
- 21 Aug, 2017 1 commit
-
-
Josh Wolfe authored
This feature is a stage 3 proposal implemented as a wrapper around ICU that categorizes singular/plural/etc grammatical forms based on a number and locale. Based on littledan's work started here: https://codereview.chromium.org/2736543002/ Bug: v8:5601 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4107cd28be72413ec43aa1ff0f4fe6e181a290f4 Reviewed-on: https://chromium-review.googlesource.com/562298 Commit-Queue: Josh Wolfe <jwolfe@igalia.com> Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47485}
-
- 11 Aug, 2017 1 commit
-
-
Georg Neis authored
R=marja@chromium.org Bug: Change-Id: I641ca830bb11b91e7098ee8d2dbec5d523bbc879 Reviewed-on: https://chromium-review.googlesource.com/612082Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47313}
-
- 09 Aug, 2017 1 commit
-
-
Caitlin Potter authored
AsyncGenerators, when resumed with a "return" completion, Await the sent value to provide consistency with syntactic return statements. This moves the await to during AsyncGeneratorResumeNext, shrinking the number of bytecodes. There's a minor change to BytecodeGenerator which removes a %_GeneratorClose() call, since it's inserted implicitly by the parser. BUG=v8:5855 TBR=neis@chromium.org Change-Id: I2965c610e5985ac24c713b481e62f6b97f96a3d8 Reviewed-on: https://chromium-review.googlesource.com/582218 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47253}
-
- 08 Aug, 2017 2 commits
-
-
Caitlin Potter authored
A spec change (https://github.com/tc39/proposal-async-iteration/commit/a0dfeba1a8029012b6e964099929b8a157818c9f) introduced a number of Await operations to the spec. In turn, this caused generated bytecode for async generators to grow drastically. This commit moves the Await within AsyncGeneratorYield (https://tc39.github.io/proposal-async-iteration/#sec-asyncgeneratoryield step 5) into a new TFJ builtin, similar in structure to AsyncGeneratorAwait, but instead of resuming the generator on resolution of the Promise, the current generator request's Promise is fulfilled instead. This results in a reduction in generated bytecode without losing any statically available information. BUG=v8:5855 Change-Id: Ib5bcf06132d221beffdea30639a7b4437030143b Reviewed-on: https://chromium-review.googlesource.com/582487 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47224}
-
Adam Klein authored
This code appears to have been wrong forever, as it only threw in strict mode (presumably predating ES2015 const). In order to get exactly the right behavior, special handling of sloppy named function expressions is required. Rather than polluting PropertyAttributes with another dummy value, this CL simply adds a bool output argument to Context::Lookup to indicate that case. Bug: v8:6677 Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b Reviewed-on: https://chromium-review.googlesource.com/602690Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47207}
-
- 01 Aug, 2017 1 commit
-
-
Caitlin Potter authored
Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
-
- 31 Jul, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit 409f84c9. Reason for revert: Breaks nosnap debug: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14288 Original change's description: > [async-iteration] implement spec-change to `yield` in async generators > > Per https://github.com/tc39/proposal-async-iteration/pull/102/files: > > AsyncGeneratorResolve no longer unwraps a value component. Instead, the > value is unwrapped before the builtin call via Await, allowing Promise > rejections to affect the generator control flow. > > Thus, all `yield <expr>` implicitly become `yield await <expr>`. > > Additionally, `return <expr>` becomes `return await <expr>`. Finally, when > the generator is resumed with `.return()`, the parameter passed to .return() > is awaited before generator execution properly continues). > > BUG=v8:5855 > R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5 > Reviewed-on: https://chromium-review.googlesource.com/523844 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47011} TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,neis@chromium.org,littledan@chromium.org,gsathya@chromium.org,caitp@igalia.com Change-Id: Ie6ad7e5410a3a89aab7a5dc68de36eb27b9354fe No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5855 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/593952Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47013}
-
Caitlin Potter authored
Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5 Reviewed-on: https://chromium-review.googlesource.com/523844 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47011}
-
- 24 Jul, 2017 2 commits
-
-
Igor Sheludko authored
This reverts commit 3d023952. Reason for revert: breaks gcc build 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} TBR=jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org Change-Id: Ie9951c87b15c8bd365ed187d7f719b8f08dd0bb5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6459 Reviewed-on: https://chromium-review.googlesource.com/583088Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46841}
-
Igor Sheludko authored
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/570250Reviewed-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}
-
- 20 Jul, 2017 1 commit
-
-
Camillo Bruni authored
- add some more const to Context getters Change-Id: Ia7560b33cae71a6015515e4337b464648e03a6f2 Reviewed-on: https://chromium-review.googlesource.com/575993Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46799}
-
- 19 Jul, 2017 1 commit
-
-
titzer authored
R=ishell@chromium.org,clemensh@chromium.org BUG=chromium:742659 Review-Url: https://codereview.chromium.org/2977113002 Cr-Commit-Position: refs/heads/master@{#46772}
-
- 17 Jul, 2017 1 commit
-
-
Yang Guo authored
R=petermarshall@chromium.org Change-Id: If181ed625015105f8bbabf29a9db3cfcf090b80a Reviewed-on: https://chromium-review.googlesource.com/574235Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#46709}
-
- 13 Jul, 2017 1 commit
-
-
Igor Sheludko authored
... that have computed name and/or require home object. This should give us the opportunity to implement initialization of name and home object values in a stub. Bug: v8:6459 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I47a1a2c185e120e86c793733cce737811f895291 Reviewed-on: https://chromium-review.googlesource.com/512802Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46638}
-
- 10 Jul, 2017 2 commits
-
-
Benedikt Meurer authored
This is the next step towards faster Map and Set iteration. It introduces the appropriate instance types for Map and Set iterators (following the pattern for Array iterators) and migrates the following builtins to the CodeStubAssembler: - Set.prototype.entries - Set.prototype.values - Map.prototype.entries - Map.prototype.keys - Map.prototype.values - %SetIteratorPrototype%.next - %MapIteratorPrototype%.next This already provides a significant performance boost for regular for-of iteration of Sets and Maps, by a factor of 5-10 depending on the input. The final step will be to inline some fast-paths into TurboFan. Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator intrinsics and runtime functions. TBR=jgruber@chromium.org Bug: v8:6344, v8:6571, chromium:740122 Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918 Reviewed-on: https://chromium-review.googlesource.com/563626 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46497}
-
Michael Achenbach authored
This reverts commit 3f22832b. Reason for revert: Layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16849 Original change's description: > [builtins] Port Map and Set iterators to CodeStubAssembler. > > This is the next step towards faster Map and Set iteration. It > introduces the appropriate instance types for Map and Set > iterators (following the pattern for Array iterators) and migrates > the following builtins to the CodeStubAssembler: > > - Set.prototype.entries > - Set.prototype.values > - Map.prototype.entries > - Map.prototype.keys > - Map.prototype.values > - %SetIteratorPrototype%.next > - %MapIteratorPrototype%.next > > This already provides a significant performance boost for regular > for-of iteration of Sets and Maps, by a factor of 5-10 depending > on the input. The final step will be to inline some fast-paths > into TurboFan. > > Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator > intrinsics and runtime functions. > > Bug: v8:6571, chromium:740122 > Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf > Reviewed-on: https://chromium-review.googlesource.com/563399 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46492} TBR=jgruber@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6571, chromium:740122 Change-Id: Iadb48d72e3b85ec8ad880e50ab7912c5502caf07 Reviewed-on: https://chromium-review.googlesource.com/564419Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46495}
-
- 08 Jul, 2017 1 commit
-
-
Benedikt Meurer authored
This is the next step towards faster Map and Set iteration. It introduces the appropriate instance types for Map and Set iterators (following the pattern for Array iterators) and migrates the following builtins to the CodeStubAssembler: - Set.prototype.entries - Set.prototype.values - Map.prototype.entries - Map.prototype.keys - Map.prototype.values - %SetIteratorPrototype%.next - %MapIteratorPrototype%.next This already provides a significant performance boost for regular for-of iteration of Sets and Maps, by a factor of 5-10 depending on the input. The final step will be to inline some fast-paths into TurboFan. Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator intrinsics and runtime functions. Bug: v8:6571, chromium:740122 Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf Reviewed-on: https://chromium-review.googlesource.com/563399 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46492}
-
- 07 Jul, 2017 2 commits
-
-
titzer authored
Instead, rely on the underlying instance types for WebAssembly.* types. R=clemensh@chromium.org, rossberg@chromium.org BUG= Review-Url: https://codereview.chromium.org/2971093003 Cr-Commit-Position: refs/heads/master@{#46478}
-
Raphael Kubo da Costa authored
Blink needs %ErrorPrototype% in order to properly set up the inheritance chain from DOMException, as specified in WebIDL: https://heycam.github.io/webidl/#es-DOMException-specialness This patch is similar to commit 5ec1cddc ("Expose %IteratorPrototype% as an intrinsic in the public API"), with the difference that there was no entry for %ErrorPrototype% in any of the mappings in contexts.h. Bug: chromium:556950, chromium:737497 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iadc5b2b844f29f6c9640b6a89769d233931366e9 Reviewed-on: https://chromium-review.googlesource.com/559058Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com> Cr-Commit-Position: refs/heads/master@{#46464}
-
- 05 Jul, 2017 1 commit
-
-
Igor Sheludko authored
This is a preliminary step before we stop swapping maps in the bootstrapper (strict/sloppy map with writable prototype <-> readonly prototype). Bug: v8:6459 Change-Id: I120550c10e98a234e283d79a8d408096601c92af Reviewed-on: https://chromium-review.googlesource.com/558879Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46403}
-
- 30 Jun, 2017 1 commit
-
-
Mathias Bynens authored
The `FAST_` prefix doesn’t make much sense — they’re all just different cases with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS` vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either. This patch renames the FAST elements kinds as follows: - e.g. FAST_ELEMENTS => PACKED_ELEMENTS - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS The following exceptions are left intact, for lack of a better name: - FAST_SLOPPY_ARGUMENTS_ELEMENTS - SLOW_SLOPPY_ARGUMENTS_ELEMENTS - FAST_STRING_WRAPPER_ELEMENTS - SLOW_STRING_WRAPPER_ELEMENTS This makes it easier to reason about elements kinds, and less confusing to explain how they’re used. R=jkummerow@chromium.org, cbruni@chromium.org BUG=v8:6548 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9 Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#46361}
-
- 29 Jun, 2017 1 commit
-
-
Leszek Swirski authored
There are very few cases where OSR code can be re-used, and where the function won't be non-concurrently optimized after OSR has happened. Maintaining the OSR code cache is unnecessary complexity, and caching OSR prevents us from e.g. seeding the optimizer with the actual OSR values. So, this patch removes it. Change-Id: Ib9223de590f35ffc1dc2ab593b7cc9fe97dde4a6 Reviewed-on: https://chromium-review.googlesource.com/552637 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#46306}
-
- 22 Jun, 2017 2 commits
-
-
Ulan Degenbaev authored
This patch also adds handling of NativeContext and BytecodeArray. BUG=chromium:694255 Change-Id: I6d4b2db03ece7346200853bd0b80daf65672787f Reviewed-on: https://chromium-review.googlesource.com/543237 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46139}
-
Daniel Ehrenberg authored
In edge cases such as the following, sloppy-mode block-scoped function hoisting is expected to occur: eval(` with({a: 1}) { function a() {} } `) In this case, there should be the equivalent of a var declaration outside of the eval, which gets set to the value of the local function a when the body of the with is executed. Previously, the way that var declarations are hoisted out of eval meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL assignment. However, such a lookup mode meant that the object in the with scope received the assignment! This patch fixes that error by marking the assignments produced by the sloppy mode block scoped function hoisting desugaring so as to generate a different runtime call which skips with scopes. Bug: chromium:720247, v8:5135 Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748 Reviewed-on: https://chromium-review.googlesource.com/529230 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46116}
-
- 19 Jun, 2017 1 commit
-
-
Peter Marshall authored
We only need to use this for certain Intrinsics defined in the spec. This CL removes unnecessary uses. Bug: v8:6474 Change-Id: I13a9f0c57d877dd65a883a38f9683d55623030d3 Reviewed-on: https://chromium-review.googlesource.com/529224 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#46012}
-
- 14 Jun, 2017 2 commits
-
-
Alexey Kozyatinskiy authored
Context::Lookup method should support Module variables. Bug: chromium:717670 Change-Id: I58d3448b9048c7f9dd7ab8b720803b3503cf91ae Reviewed-on: https://chromium-review.googlesource.com/519389 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45950}
-
Caitlin Potter authored
Simplifies the implementation of IteratorClose in IteratorBuiltinsAssembler, and makes clear that it is only invoked when an exception occurs. Adds exception handling support to GetIterator, IteratorStep, and IteratorCloseOnException. Moves the Promise.all resolveElement closure and it's caller to builtins-promise-gen.cc. Instead of creating an internal array (and copying its elements into a result array), a single JSArray is allocated, and appended with BuildAppendJSArray(), falling back to %CreateDataProperty(), and elements are updated in the resolve closure the same way. This should always be unobservable. This CL increases the size of snapshot_blob.bin on an x64.release build by 8.51kb BUG=v8:5343 R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org, hpayer@chromium.org, tebbi@chromium.org Change-Id: I29c4a529154ef49ad65555ce6ddc2c5b7c9de6b3 Reviewed-on: https://chromium-review.googlesource.com/508473 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45946}
-
- 13 Jun, 2017 1 commit
-
-
Ben Smith authored
It is only attached to the global object if the --harmony-sharedarraybuffer flag is enabled, but this allows more objects to be added to the snapshot which seems to reduce the amount of heap memory used per context. Bug: chromium:724053 Change-Id: I5d1115a0e3ed9abf41cb3ab80d19d622cbef7b93 Reviewed-on: https://chromium-review.googlesource.com/534594Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#45930}
-
- 12 Jun, 2017 1 commit
-
-
Igor Sheludko authored
... by reading the |map_index| value from the SharedFunctionInfo's |compiler_hints| field directly. Bug: v8:6459 Change-Id: I32c4c903b16fa9f7e7da755667dadef7fadfc5e0 Reviewed-on: https://chromium-review.googlesource.com/531024 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#45871}
-
- 15 May, 2017 2 commits
-
-
Clemens Hammacher authored
This reverts commit 7ef1df85. Reason for revert: Breaks inspector/debugger/get-possible-breakpoints-restrict-to-function: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/13191/steps/Check/logs/get-possible-breakpoi.. Original change's description: > [builtins] port Promise.all to CSA > > Introduces CodeStubAssembler helpers for common Iterator operations > (GetIterator, IteratorStep, IteratorClose). > > Moves the Promise.all resolveElement closure and it's caller to > builtins-promise-gen.cc. > > Instead of creating an internal array (and copying its elements into a result > array), a single JSArray is allocated, and appended with BuildAppendJSArray(), > falling back to %CreateDataProperty(), and elements are updated in the resolve > closure the same way. This should always be unobservable. > > This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb > > BUG=v8:5343 > R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org > > Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418 > Reviewed-on: https://chromium-review.googlesource.com/497974 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45306} TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,ishell@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5343 Change-Id: I831738003643561fa628266af2bcebbb18000e55 Reviewed-on: https://chromium-review.googlesource.com/506014Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45313}
-
Caitlin Potter authored
Introduces CodeStubAssembler helpers for common Iterator operations (GetIterator, IteratorStep, IteratorClose). Moves the Promise.all resolveElement closure and it's caller to builtins-promise-gen.cc. Instead of creating an internal array (and copying its elements into a result array), a single JSArray is allocated, and appended with BuildAppendJSArray(), falling back to %CreateDataProperty(), and elements are updated in the resolve closure the same way. This should always be unobservable. This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb BUG=v8:5343 R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418 Reviewed-on: https://chromium-review.googlesource.com/497974 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45306}
-
- 10 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
-
- 08 May, 2017 1 commit
-
-
Ross McIlroy authored
This reverts commit 662aa425. Reason for revert: Crashing on Canary BUG=chromium:718891 Original change's description: > Reland: [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > TBR=yangguo@chromium.org,ulan@chromium.org > > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 > Reviewed-on: https://chromium-review.googlesource.com/494487 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45084} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6246 Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82 Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45174}
-
- 04 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45084}
-