AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
00e806ff3e
v8/test/cctest/interpreter/bytecode_expectations/PrivateAccessorDeclaration.golden

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

383 lines
11 KiB
Plaintext
Raw Normal View History

[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: yes
---
snippet: "
{
class A {
get #a() { return 1; }
set #a(val) { }
}
}
"
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
frame size: 7
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
parameter count: 1
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
bytecode array length: 57
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
bytecodes: [
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(1),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 30 E> */ B(CallRuntime), U16(Runtime::kCreatePrivateBrandSymbol), R(3), U8(1),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaTheHole),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(3), U8(0), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star2),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaConstant), U8(1),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(Mov), R(2), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(3),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(4), U8(1), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(5), U8(2), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CallRuntime), U16(Runtime::kCreatePrivateAccessors), R(5), U8(2),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(1),
B(Mov), R(2), R(0),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaUndefined),
/* 101 S> */ B(Return),
]
constant pool: [
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["A"],
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
]
handlers: [
]
---
snippet: "
{
class B {
get #b() { return 1; }
}
}
"
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
frame size: 7
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
parameter count: 1
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
bytecode array length: 54
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
bytecodes: [
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(1),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 30 E> */ B(CallRuntime), U16(Runtime::kCreatePrivateBrandSymbol), R(3), U8(1),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaTheHole),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(3), U8(0), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star2),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaConstant), U8(1),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(Mov), R(2), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(3),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(4), U8(1), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaNull),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CallRuntime), U16(Runtime::kCreatePrivateAccessors), R(5), U8(2),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(1),
B(Mov), R(2), R(0),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaUndefined),
/* 81 S> */ B(Return),
]
constant pool: [
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["B"],
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
]
handlers: [
]
---
snippet: "
{
class C {
set #c(val) { }
}
}
"
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
frame size: 7
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
parameter count: 1
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
bytecode array length: 54
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
bytecodes: [
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(1),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 30 E> */ B(CallRuntime), U16(Runtime::kCreatePrivateBrandSymbol), R(3), U8(1),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaTheHole),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(3), U8(0), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star2),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaConstant), U8(1),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(Mov), R(2), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(3),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaNull),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(4), U8(1), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CallRuntime), U16(Runtime::kCreatePrivateAccessors), R(5), U8(2),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(1),
B(Mov), R(2), R(0),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaUndefined),
/* 74 S> */ B(Return),
]
constant pool: [
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["C"],
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
]
handlers: [
]
---
snippet: "
{
class D {
get #d() { return 1; }
set #d(val) { }
}
class E extends D {
get #e() { return 2; }
set #e(val) { }
}
}
"
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
frame size: 8
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
parameter count: 1
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
bytecode array length: 113
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
bytecodes: [
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 30 E> */ B(CallRuntime), U16(Runtime::kCreatePrivateBrandSymbol), R(4), U8(1),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaTheHole),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star7),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(3), U8(0), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaConstant), U8(1),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(Mov), R(3), R(6),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(3),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(4), U8(1), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(5), U8(2), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star7),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CallRuntime), U16(Runtime::kCreatePrivateAccessors), R(6), U8(2),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(2),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(Mov), R(3), R(0),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(6),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(8),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 38 E> */ B(CallRuntime), U16(Runtime::kCreatePrivateBrandSymbol), R(4), U8(1),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
/* 118 E> */ B(CreateClosure), U8(9), U8(3), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaConstant), U8(7),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(Mov), R(3), R(6),
B(Mov), R(0), R(7),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(3),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(10), U8(4), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(11), U8(5), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star7),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CallRuntime), U16(Runtime::kCreatePrivateAccessors), R(6), U8(2),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(2),
B(Mov), R(3), R(1),
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
B(LdaUndefined),
/* 175 S> */ B(Return),
]
constant pool: [
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["D"],
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["E"],
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
]
handlers: [
]
---
snippet: "
{
class A { foo() {} }
class C extends A {
get #a() { return super.foo; }
}
new C();
}
"
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
frame size: 8
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
parameter count: 1
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
bytecode array length: 101
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
bytecodes: [
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaTheHole),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 30 E> */ B(CreateClosure), U8(2), U8(0), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaConstant), U8(1),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(3), U8(1), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star7),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(4),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(2),
B(Mov), R(5), R(0),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(4),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(6),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 38 E> */ B(CallRuntime), U16(Runtime::kCreatePrivateBrandSymbol), R(4), U8(1),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
/* 77 E> */ B(CreateClosure), U8(7), U8(2), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaConstant), U8(5),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(Mov), R(3), R(6),
B(Mov), R(0), R(7),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(3),
Reland2 [super] Store home object in Context instead of JSFunction Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
2021-01-29 08:24:03 +00:00
B(StaCurrentContextSlot), U8(4),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
Reland2 [super] Store home object in Context instead of JSFunction Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
2021-01-29 08:24:03 +00:00
B(Ldar), R(6),
B(StaCurrentContextSlot), U8(5),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(8), U8(3), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaNull),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star7),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CallRuntime), U16(Runtime::kCreatePrivateAccessors), R(6), U8(2),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(2),
B(Mov), R(3), R(1),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
/* 122 S> */ B(Ldar), R(1),
Reland2 [super] Store home object in Context instead of JSFunction Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
2021-01-29 08:24:03 +00:00
/* 122 E> */ B(Construct), R(1), R(0), U8(0), U8(0),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaUndefined),
/* 133 S> */ B(Return),
]
constant pool: [
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["C"],
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
]
handlers: [
]
---
snippet: "
{
class A { foo(val) {} }
class C extends A {
set #a(val) { super.foo(val); }
}
new C();
}
"
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
frame size: 8
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
parameter count: 1
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
bytecode array length: 101
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
bytecodes: [
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaTheHole),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 30 E> */ B(CreateClosure), U8(2), U8(0), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaConstant), U8(1),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(3), U8(1), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star7),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(4),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(2),
B(Mov), R(5), R(0),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
B(CreateBlockContext), U8(4),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(6),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star4),
[bytecode-generator] Move source code position for classes Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
2021-11-16 14:20:34 +00:00
/* 38 E> */ B(CallRuntime), U16(Runtime::kCreatePrivateBrandSymbol), R(4), U8(1),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
/* 80 E> */ B(CreateClosure), U8(7), U8(2), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star3),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaConstant), U8(5),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(Mov), R(3), R(6),
B(Mov), R(0), R(7),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(3),
Reland2 [super] Store home object in Context instead of JSFunction Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
2021-01-29 08:24:03 +00:00
B(StaCurrentContextSlot), U8(4),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star5),
Reland2 [super] Store home object in Context instead of JSFunction Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
2021-01-29 08:24:03 +00:00
B(Ldar), R(6),
B(StaCurrentContextSlot), U8(5),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaNull),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star6),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(CreateClosure), U8(8), U8(3), U8(2),
Reland "[interpreter] Short Star bytecode" This is a reland of cf93071c91a932996a4df2e2d8880aca3cffbe28 Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
2021-02-17 14:36:58 +00:00
B(Star7),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CallRuntime), U16(Runtime::kCreatePrivateAccessors), R(6), U8(2),
Reland x3 "[runtime] Remove extension slots from context objects" Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
2019-10-22 12:59:24 +00:00
B(StaCurrentContextSlot), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PopContext), R(2),
B(Mov), R(3), R(1),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
/* 126 S> */ B(Ldar), R(1),
Reland2 [super] Store home object in Context instead of JSFunction Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
2021-01-29 08:24:03 +00:00
/* 126 E> */ B(Construct), R(1), R(0), U8(0), U8(0),
[class] implement private accessor declarations This patch implements the declaration of private accessors. When iterating over the class properties, we track private accessors associated with the same name in a ZoneHashMap. Once we get to all the necessary components for a private name (we know statically whether we should expect only a setter, only a getter, or both), we emit a call to a runtime function `CreatePrivateAccessors` that creates an AccessorPair, and store the components in it. The AccessorPair is then associated with the private name variable and stored in the context for later retrieval when the private accessors are accessed. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63284}
2019-08-20 14:48:28 +00:00
B(LdaUndefined),
/* 137 S> */ B(Return),
]
constant pool: [
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SCOPE_INFO_TYPE,
FIXED_ARRAY_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["C"],
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
SHARED_FUNCTION_INFO_TYPE,
[class] fix super access in private methods This patch stores the home objects in private methods that access super properties. Bug: v8:8330 Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63113}
2019-08-07 05:14:45 +00:00
]
handlers: [
]
Reference in New Issue Copy Permalink