- 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}
-
- 13 Sep, 2017 1 commit
-
-
Jakob Kummerow authored
Bug: v8:6791 Change-Id: I2da258f7db6c74d764c674eb8d550418a566c5ea Reviewed-on: https://chromium-review.googlesource.com/662138 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#48002}
-
- 11 Sep, 2017 2 commits
-
-
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}
-
jgruber authored
This fixes two issues related to Code object allocation: Code objects need to be aligned to kCodeAlignment (= 32), and the instruction cache needs to be flushed after deserialization. Both bugs combined manifested as a crash at a basically arbitrary point in the code after the Runtime::kDeserializeLazy call: 0x286bc8dc: blx r12 // Call to Runtime::kDeserializeLazy, // generated through // GenerateTailCallToReturnedCode. 0x286bc8e0: mov r2, r0 // This seemingly innocent register move // crashes hard. Bug: v8:6624,v8:6796 Change-Id: I88c7eaf57ac851745fb7e800c92b0f5978b33466 Reviewed-on: https://chromium-review.googlesource.com/660119Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47947}
-
- 08 Sep, 2017 1 commit
-
-
Michael Starzinger authored
R=mvstanton@chromium.org BUG=v8:6409 Change-Id: I9252055a395287381d2646fedc59c8c376333694 Reviewed-on: https://chromium-review.googlesource.com/652469Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47927}
-
- 07 Sep, 2017 1 commit
-
-
Michael Starzinger authored
This finally allows to include the factory.h header without having to also inlcude the object-inl.h inline header. It will in turn enable the removal of the last inline header inclusion violation. R=marja@chromium.org Change-Id: Ice2821e1f74cf428d80c8ebf606a218026f37677 Reviewed-on: https://chromium-review.googlesource.com/654862Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47880}
-
- 30 Aug, 2017 2 commits
-
-
Michael Lippautz authored
Aligns behavior with other allocate calls in factory that allow choosing the generation depending on the use case. Bug: v8:6771 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I63b95de7e664a51af8ca24a75f2122dfe1792c42 Reviewed-on: https://chromium-review.googlesource.com/642799Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47707}
-
Benedikt Meurer authored
Introduce a proper empty_descriptor_array, which has the proper layout (length is 2 and the two fields are set properly). Also add a special EnumCache class and a matching empty_enum_cache. The contract now is that we only need to check the EnumLength on the map to know whether we are allowed to use the enum cache. This greatly simplifies the handling of the enum cache (and also the descriptor arrays), especially for the future work on optimizing keyed access via the enum cache indices. Bug: v8:6702 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I5ef517a3041163cd65ef003f691139ea52233e83 Reviewed-on: https://chromium-review.googlesource.com/641030 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47697}
-
- 23 Aug, 2017 1 commit
-
-
Georg Neis authored
This moves Module and other module-related classes and definitions out of src/objects{.h,-inl.h,.cc} into src/objects/module{.h,-inl.h,.cc}. Also moves the contents of src/objects/module-info.h there. R=marja@chromium.org Bug: v8:1569, v8:5402 Change-Id: I49064bb4a5c5a6f409274c287e06e8dda351d615 Reviewed-on: https://chromium-review.googlesource.com/626818 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47540}
-
- 16 Aug, 2017 1 commit
-
-
Yang Guo authored
This removes: - CodeBreakIterator for FCG code. - RelocModes for debug breaks. - Code generator for debug break slots. - GC support for debug break slots. - Code flag to indicate code with debug break slots. - Builtin type DBG. - Mechanisms to replace FCG code in the debugger and LiveEdit. - Runtime entry to the debugger from debug break slots. R=bmeurer@chromium.org, rmcilroy@chromium.org, ulan@chromium.org Bug: v8:6409 Change-Id: I5662c8800e3ef1b1584ad107bfe0aae26c9d8abb Reviewed-on: https://chromium-review.googlesource.com/613263Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47364}
-
- 03 Aug, 2017 1 commit
-
-
Michael Starzinger authored
The predicate in question used to report true on both, Crankshaft and TurboFan code. It has hence become obsolete and can be replaced by the existing {Code::is_turbofanned} predicate. This also frees up a bit in the second kind-specific bit field. R=jarin@chromium.org BUG=v8:6408 Change-Id: I204d7dd78a639c752c9749fd305c7006c6b6aca3 Reviewed-on: https://chromium-review.googlesource.com/599868Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47125}
-
- 02 Aug, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
My goal was to move breakpoint API to native with minimal changes around, so on inspector side we use v8::debug::BreakpointId instead of String16, on v8::internal::Debug we use i::BreakPoint object instead of break point object created inside of debug.js. There are a lot of opportunities how we can improve breakpoints (at least we can avoid some of linear lookups to speedup implementation) but I think that as first step we need to remove mirrors/debug.js APIs. Drive by: debugger-script.js and usage of debugger context in inspector code base. R=yangguo@chromium.org,jgruber@chromium.org,clemensh@chromium.org Bug: v8:5510,chromium:652939 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I0b17972c39053dd4989bbe26db2bb0b88ca378f7 Reviewed-on: https://chromium-review.googlesource.com/593156Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47091}
-
- 27 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
-
- 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}
-
- 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}
-
- 11 Jul, 2017 1 commit
-
-
Sathya Gunasekaran authored
This patch changes the backing store of slow properties to be a new instance type called PropertyArray. Currently the only difference between this and a FixedArray is the map. A future patch will change the length property to store the hash code. Bug: v8:5717, v8:6404 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iaebc98f42e6d93c1392772e6f837787beb64afec Reviewed-on: https://chromium-review.googlesource.com/539028Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#46569}
-
- 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 1 commit
-
-
Igor Sheludko authored
... but use proper map for functions with readonly prototype from the start. Bug: v8:6459 Change-Id: I432d4969822e7cc4c2ba83e103f550d1c4f2e234 Reviewed-on: https://chromium-review.googlesource.com/563199Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46487}
-
- 06 Jul, 2017 1 commit
-
-
Benedikt Meurer authored
This is the first step in optimizing Map and Set iterators. This ports all the base functionality including - Set.prototype.entries - Set.prototype.values - %SetPrototypeIterator%.next - Map.prototype.entries - Map.prototype.keys - Map.prototype.values - %MapPrototypeIterator%.next to C++ and removes all the dead code and the previous half JavaScript implementation. The next step is to port core parts to CodeStubAssembler and finally inline the fast-paths into TurboFan directly. The relevant design document is at: https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8 Most of this work is very similar to how the Array iterator works and we mostly follow the same process for the implementation. R=jgruber@chromium.org Bug: v8:6571 Change-Id: Ieb253d6705ba4077c697a5ff0cb6f87f9c4056ff Reviewed-on: https://chromium-review.googlesource.com/561138Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46441}
-
- 03 Jul, 2017 1 commit
-
-
Igor Sheludko authored
Bug: v8:6459 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I34d6203c7f26c54423789699e4263ce815171d3f Reviewed-on: https://chromium-review.googlesource.com/558874Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46380}
-
- 30 Jun, 2017 2 commits
-
-
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}
-
Marja Hölttä authored
This way, each lazy function needs to handle only the data relevant to itself. This reduced data handling overheads. Other changes: 1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy function compilation is only done in the main thread. 2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because: - The data looks fundamentally different when we're producing it and when we're consuming it. - Cleanly separates the operations we can do in the "producing phase" and in the "consuming phase". Bug: v8:5516 Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33 Reviewed-on: https://chromium-review.googlesource.com/528094 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46347}
-
- 29 Jun, 2017 1 commit
-
-
Sathya Gunasekaran authored
Previously V8 created a promise to return to userland, but instead we let the embedder create and track the promise. Bug: v8:5785 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I8903ffbabf3a256f1c8df844a656a873da304586 Reviewed-on: https://chromium-review.googlesource.com/492646 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46333}
-
- 27 Jun, 2017 1 commit
-
-
Toon Verwaest authored
Bug: Change-Id: I56bfd921d63783ddaa74133dde5f3daf776e68ca Reviewed-on: https://chromium-review.googlesource.com/548115 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46250}
-
- 20 Jun, 2017 1 commit
-
-
Sathya Gunasekaran authored
Bug: v8:6443 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I20b1006a5c5ff24a730f15286cf0f340ba047b78 Reviewed-on: https://chromium-review.googlesource.com/526001Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#46034}
-
- 14 Jun, 2017 1 commit
-
-
Marja Hölttä authored
These were too aggressively de-inlined as part of https://chromium-review.googlesource.com/c/528102 . BUG=chromium:733161 Change-Id: I88e9f969dcd6142cbbbb2662edd8108ad687c522 Reviewed-on: https://chromium-review.googlesource.com/535640Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#45942}
-
- 13 Jun, 2017 1 commit
-
-
Marja Hölttä authored
This is an unexciting CL (doesn't make the build step situation any better) but enables moving FixedArray & co next. BUG=v8:5402,v8:6474 Change-Id: Ia36eb3973e6242f6f68e02b9f583dc552d48422f Reviewed-on: https://chromium-review.googlesource.com/529168 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45889}
-
- 12 Jun, 2017 1 commit
-
-
Marja Hölttä authored
BUG=v8:5402,v8:6474 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id38249fe9dc88001218aa1faa1b31c9d2f9703d1 Reviewed-on: https://chromium-review.googlesource.com/528102 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45853}
-
- 06 Jun, 2017 2 commits
-
-
Igor Sheludko authored
Properly propagate the fact that the function has a statically known name from parser to SharedFunctionInfo objects. The empty string that has been set as name before this CL does not help to distinguish cases like: var o1 = { ''(){} }; var o1 = { [foo()](){} }; or var o2 = { get ''(){} }; var o2 = { get [foo()](){} }; This is a preliminary step for using different layouts for closure objects with and without computed names. TBR=bmeurer@chromium.org, marja@chromium.org Bug: v8:6459 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d Reviewed-on: https://chromium-review.googlesource.com/522073 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45744}
-
jgruber authored
This CL implements general infrastructure for block coverage together with initial support for if-statements. Coverage output can be generated in lcov format by d8 as follows: $ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js $ genhtml ~/simple-if.lcov -o ~/simple-if $ chrome ~/simple-if/index.html A high level overview of the implementation follows: The parser now collects source ranges unconditionally for relevant AST nodes. Memory overhead is very low and this seemed like the cleanest and simplest alternative. Bytecode generation uses these ranges to allocate coverage slots and insert IncBlockCounter instructions (e.g. at the beginning of then- and else blocks for if-statements). The slot-range mapping is generated here and passed on through CompilationInfo, and is later accessible through the SharedFunctionInfo. The IncBlockCounter bytecode fetches the slot-range mapping (called CoverageInfo) from the shared function info and simply increments the counter. We don't collect native-context-specific counts as they are irrelevant to our use-cases. Coverage information is finally generated on-demand through Coverage::Collect. The only current consumer is a d8 front-end with lcov-style output, but the short-term goal is to expose this through the inspector protocol. BUG=v8:6000 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng Review-Url: https://codereview.chromium.org/2882973002 Cr-Commit-Position: refs/heads/master@{#45737}
-
- 29 May, 2017 1 commit
-
-
Sathya Gunasekaran authored
Implements the Allocate, Add, and HasKey operations. Also, adds GC support for this new instance type. Bug: v8:6443 Change-Id: I1cc7ba2faead2a11f7b0381a57858629e123aee6 Reviewed-on: https://chromium-review.googlesource.com/500447 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#45551}
-
- 23 May, 2017 3 commits
-
-
jgruber authored
BUG=v8:5402 Review-Url: https://codereview.chromium.org/2900713004 Cr-Commit-Position: refs/heads/master@{#45486}
-
machenbach authored
Revert of [es2015] Precompute the descriptive string for symbols. (patchset #3 id:40001 of https://codereview.chromium.org/2900703002/ ) Reason for revert: Speculative revert for: https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/8901 Original issue's description: > [es2015] Precompute the descriptive string for symbols. > > Previously the String constructor and the Symbol.prototype.toString > methods had to compute the descriptive string for a Symbol on the fly, > which can produce a lot of garbage when this happens a lot, i.e. when > the String representation of a Symbol is used often. Now instead of > doing this on-demand we can just do it upfront when creating the Symbol. > > That way we also ensure that we won't throw an exception when accessing > the descriptive string of a Symbol, due to potential String length > overflow, but have the exception during Symbol creation upfront, which > is a lot less surprising behavior. > > BUG=v8:6278,v8:6344,v8:6350 > TBR=mlippautz@chromium.org > R=ishell@chromium.org > > Review-Url: https://codereview.chromium.org/2900703002 > Cr-Commit-Position: refs/heads/master@{#45479} > Committed: https://chromium.googlesource.com/v8/v8/+/e87573822e1c0c041c03f2b60599b0ab9256422f TBR=ishell@chromium.org,mlippautz@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6278,v8:6344,v8:6350 Review-Url: https://codereview.chromium.org/2903533002 Cr-Commit-Position: refs/heads/master@{#45483}
-
bmeurer authored
Previously the String constructor and the Symbol.prototype.toString methods had to compute the descriptive string for a Symbol on the fly, which can produce a lot of garbage when this happens a lot, i.e. when the String representation of a Symbol is used often. Now instead of doing this on-demand we can just do it upfront when creating the Symbol. That way we also ensure that we won't throw an exception when accessing the descriptive string of a Symbol, due to potential String length overflow, but have the exception during Symbol creation upfront, which is a lot less surprising behavior. BUG=v8:6278,v8:6344,v8:6350 TBR=mlippautz@chromium.org R=ishell@chromium.org Review-Url: https://codereview.chromium.org/2900703002 Cr-Commit-Position: refs/heads/master@{#45479}
-
- 28 Apr, 2017 1 commit
-
-
Marja Hölttä authored
BUG=v8:6325,v8:5402 Change-Id: If0c975fe377c0178c488fc1bedd02f9c8289ebbc Reviewed-on: https://chromium-review.googlesource.com/490086Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44979}
-
- 27 Apr, 2017 1 commit
-
-
cbruni authored
With this CL we reduce the difference between directly using a null prototype in a literal or using Object.create(null). - The EmitFastCloneShallowObject builtin now supports cloning slow object boilerplates. - Unified behavior to find the matching Map and instantiating it for Object.create(null) and literals with a null prototype. - Cleanup of literal type parameter of CompileTimeValue, now in sync with ObjectLiteral flags. Review-Url: https://codereview.chromium.org/2445333002 Cr-Commit-Position: refs/heads/master@{#44941}
-
- 18 Apr, 2017 1 commit
-
-
Marja Hölttä authored
BUG=v8:5516 Change-Id: Ie2e41ffa82c63788e285641232a5d555155b0d13 Reviewed-on: https://chromium-review.googlesource.com/480239 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44689}
-