- 27 Nov, 2017 1 commit
-
-
Sathya Gunasekaran authored
Previously, the class fields initializer function was stored on a synthetic context allocated variable. This approach had sevaral problems: - We didn't know that class literal had fields until after we had completely parsed the class literal. This meant that we had to go back and fix up the scope of the constructor to have this synthetic variable. This resulted in mismatch between parser and preparsed scope data. - This synthetic variable could potentially resolve to an initializer of an outer class. For ex: class X extends Object { c = 1; constructor() { var t = () => { class P extends Object { constructor() { var t = () => { super(); }; t(); } } super(); } t(); } } In this the inner class P could access the outer class X's initiliazer function. We would have to maintain extra metadata to make sure this doesn't happen. Instead this new approach uses a private symbol to store the initializer function on the class constructor itself. For the base constructor case, we can simply check for a bit on the constructor function literal to see if we need to emit code that loads and calls this initializer function. Therefore, we don't pay the cost of loading this function in case there are no class fields. For the derived constructor case, there are two possiblities: (a) We are in a super() call directly in the derived constructor: In this case we can do a check similar to the base constructor check, we can check for a bit on the derived constructor and emit code for loading and calling the initializer function. This is usually the common case and we don't pay any cost for not using class fields. (b) We are in a super() call inside an arrow function in the derived constructor: In this case, we /always/ emit code to load and call the initializer function. If the function doesn't exist then we have undefined and we don't call anything. Otherwise we call the function. super() can't be called twice so even if we emit code to load and call the initializer function multiple times, it doesn't matter because it would have already been an error. Bug: v8:5367 Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88 Reviewed-on: https://chromium-review.googlesource.com/781660 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49628}
-
- 27 Oct, 2017 1 commit
-
-
Adam Klein authored
This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
-
- 18 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
This CL fixes all occurences that don't require special OWNER reviews, or can be reviewed by Michi. After this one, we should be able to reenable the readability/check cpplint check. R=mstarzinger@chromium.org Bug: v8:6837, v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62 Reviewed-on: https://chromium-review.googlesource.com/721120 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48670}
-
- 15 May, 2017 1 commit
-
-
Leszek Swirski authored
Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
-
- 15 Feb, 2017 1 commit
-
-
caitp authored
When --harmony-async-iteration is enabled, it is now possible to use the for-await-of loop, which uses the Async Iteration protocol rather than the ordinary ES6 Iteration protocol. the Async-from-Sync Iterator object is not implemented in this CL, and so for-await-of loops will abort execution if the iterated object does not have a Symbol.asyncIterator() method. Async-from-Sync Iterators are implemented seperately in https://codereview.chromium.org/2645313003/ BUG=v8:5855, v8:4483 R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org Review-Url: https://codereview.chromium.org/2637403008 Cr-Commit-Position: refs/heads/master@{#43224}
-
- 10 Feb, 2017 1 commit
-
-
Leszek Swirski authored
Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
-
- 03 Jan, 2017 1 commit
-
-
adamk authored
This triggered on a CL I was working on today, figured I'd share my work. R=mythria@chromium.org, rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2601213002 Cr-Commit-Position: refs/heads/master@{#42043}
-
- 17 Oct, 2016 1 commit
-
-
jochen authored
R=machenbach@chromium.org,titzer@chromium.org,bmeurer@chromium.org,jgruber@chromium.org BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe Review-Url: https://codereview.chromium.org/2416243002 Cr-Commit-Position: refs/heads/master@{#40350}
-
- 03 Oct, 2016 1 commit
-
-
leszeks authored
Hashmaps with a simple key equality method (comparing pointers) don't need to waste cycles (and branches) comparing hash values, as the key comparison is cheap. This patch modifies the hashmap's MatchFun to take the hashes as well as the keys, thus allowing the MatchFun to ignore the hashes. This allows slightly cleaner generated code, especially when the MatchFun is inlined. BUG= Review-Url: https://codereview.chromium.org/2381303002 Cr-Commit-Position: refs/heads/master@{#39932}
-
- 29 Sep, 2016 1 commit
-
-
leszeks authored
Uses the base hashmap to store the ConstantArrayBuilder's constant map, which slightly improves the performance of ConstantArrayBuilder::Insert. Includes a small overload of the hashmap LookupOrInsert method, which allows passing in a value creation function instead of just default initialising new values. On Octane's codeload, this gives (on my machine) a 0.27% improvement, which doesn't sound like a lot but I guess every little helps. Review-Url: https://codereview.chromium.org/2336553002 Cr-Commit-Position: refs/heads/master@{#39883}
-
- 20 Sep, 2016 1 commit
-
-
heimbuef authored
This is some initial cleanup to keep /src clean. The AccountingAllocator is actually exclusively used by zones and this common subfolder makes that more clear. BUG=v8:5409 Review-Url: https://codereview.chromium.org/2344143003 Cr-Commit-Position: refs/heads/master@{#39558}
-
- 18 Aug, 2016 1 commit
-
-
rmcilroy authored
Removes all accesses to the Isolate during bytecode generation and the bytecode pipeline. Adds an DisallowIsolateAccessScope which is used to enforce this invariant within the BytecodeGenerator. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2242193002 Cr-Commit-Position: refs/heads/master@{#38716}
-
- 10 Aug, 2016 1 commit
-
-
rmcilroy authored
Don't allocate handles in the bytecode array writer, to allow off-thread bytecode generation. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2226333002 Cr-Commit-Position: refs/heads/master@{#38550}
-
- 05 Aug, 2016 1 commit
-
-
rmcilroy authored
Changes ConstantPoolArrayBuilder to do object lookups using the location of the handles, rather than dereferencing the handles and comparing the objects. This also updates CanonicalHandleScope when internalizing AST nodes to ensure that duplicate objects share the same handles and so are only added to the constant pool once. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2204243003 Cr-Commit-Position: refs/heads/master@{#38366}
-
- 25 Jul, 2016 1 commit
-
-
rmcilroy authored
Move the logic for allocating the global declaration pair array from VisitDeclarations to a later step. This is required for concurrent bytecode generation. This change requires adding support for reserving fixed constant pool array entries, which can be later updated with the value of the literal. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2167763003 Cr-Commit-Position: refs/heads/master@{#38010}
-
- 21 Mar, 2016 1 commit
-
-
oth authored
This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
-
- 26 Feb, 2016 1 commit
-
-
oth authored
Extends the constant pool to deal with more slices. Adds ReadUnalignedUInt32(). BUG=v8:4280,v8:4747 LOG=N Review URL: https://codereview.chromium.org/1731893003 Cr-Commit-Position: refs/heads/master@{#34319}
-
- 02 Feb, 2016 1 commit
-
-
oth authored
Moves the temporary register allocator out of the bytecode array builder into TemporaryRegisterAllocator class and adds unittests. Particular must be taken around the translation window boundary motivating the addition of tests. Also adds a Clear() method to IdentityMap() which is called by the destructor. This allows classes to hold an IdentityMap if they are zone allocated. Classes must call Clear() before the zone is re-cycled or face v8 heap corruption. BUG=v8:4280,v8:4675 LOG=N Review URL: https://codereview.chromium.org/1651133002 Cr-Commit-Position: refs/heads/master@{#33686}
-
- 20 Jan, 2016 1 commit
-
-
mstarzinger authored
R=oth@chromium.org Review URL: https://codereview.chromium.org/1608693004 Cr-Commit-Position: refs/heads/master@{#33401}
-
- 05 Jan, 2016 1 commit
-
-
oth authored
This increases the size of addressable constant pool entries for jumps to match other bytecodes using operands indexing the constant pool. This change also introduces reservations for constant pool entries. Reservations are used for forward jumps to ensure a constant pool entry will be available when the jump target (label) is bound and the jump is patched up in the bytecode array. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1546683002 Cr-Commit-Position: refs/heads/master@{#33125}
-