- 16 Sep, 2016 1 commit
-
-
neis authored
Rename JSModule to Module and make it a Struct rather than a JSObject. We will later add a separate JSModuleNamespace object to implement the 'import * as foo' syntax. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2345823002 Cr-Commit-Position: refs/heads/master@{#39477}
-
- 15 Sep, 2016 1 commit
-
-
franzih authored
We used to intercept function definitions, but not declarations. GenericNamedPropertySetterCallback now also intercepts function declarations. For definitions, we call DeclareGlobal and then InitializeVarGlobal. For declarations, we never call InitializeVarGlobal, thus we must check for interceptors in DeclareGlobal. If the semantics of a redeclaration are wrong, e.g., redeclaring a read-only property, an exception is thrown independent of whether an interceptor is installed. Usually, i.e., not during a declaration, we only throw if the call is not successfully intercepted. BUG=v8:5375 Review-Url: https://codereview.chromium.org/2334733002 Cr-Commit-Position: refs/heads/master@{#39450}
-
- 12 Sep, 2016 3 commits
-
-
neis authored
This adds partial support of exports to the runtime system and to the interpreter. It introduces a new HeapObject JSModule that maps each of the module's export names to a Cell containing the exported value. Several aspects of this implementation are subject to change in follow-up CLs. BUG=v8:1569 Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17 Review-Url: https://codereview.chromium.org/2302783002 Cr-Original-Commit-Position: refs/heads/master@{#39341} Cr-Commit-Position: refs/heads/master@{#39352}
-
neis authored
Revert of [modules] Basic support of exports (patchset #10 id:180001 of https://codereview.chromium.org/2302783002/ ) Reason for revert: Failures related to deopt. Original issue's description: > [modules] Basic support of exports > > This adds partial support of exports to the runtime system and > to the interpreter. It introduces a new HeapObject JSModule that > maps each of the module's export names to a Cell containing the > exported value. > > Several aspects of this implementation are subject to change in > follow-up CLs. > > BUG=v8:1569 > > Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17 > Cr-Commit-Position: refs/heads/master@{#39341} TBR=adamk@chromium.org,rmcilroy@chromium.org,ulan@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:1569 Review-Url: https://codereview.chromium.org/2328283002 Cr-Commit-Position: refs/heads/master@{#39345}
-
neis authored
This adds partial support of exports to the runtime system and to the interpreter. It introduces a new HeapObject JSModule that maps each of the module's export names to a Cell containing the exported value. Several aspects of this implementation are subject to change in follow-up CLs. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2302783002 Cr-Commit-Position: refs/heads/master@{#39341}
-
- 06 Sep, 2016 1 commit
-
-
jochen authored
This will allow for chaining ScopeInfos together to form the same chains as contexts chains currently do. BUG=v8:5215 R=mstarzinger@chromium.org,marja@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2314483002 Cr-Commit-Position: refs/heads/master@{#39192}
-
- 05 Sep, 2016 1 commit
-
-
jochen authored
Since the extension field is already used for the catch name, store a ContextExtension there instead. In the future, this will allow for chaining ScopeInfos together, so we no longer need a context chain for lazy parsing / compilation. BUG=v8:5215 R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org Review-Url: https://codereview.chromium.org/2302013002 Cr-Commit-Position: refs/heads/master@{#39164}
-
- 01 Sep, 2016 1 commit
-
-
jochen authored
The plan is to also use it for With and Catch scopes, so all kinds of contexts have a pointer back to their ScopeInfo R=neis@chromium.org,marja@chromium.org BUG=v8:5215 Review-Url: https://codereview.chromium.org/2301913002 Cr-Commit-Position: refs/heads/master@{#39092}
-
- 29 Aug, 2016 1 commit
-
-
verwaest authored
This additionally gets rid of old approach to global shortcuts. BUG=v8:5209 Review-Url: https://codereview.chromium.org/2287173002 Cr-Commit-Position: refs/heads/master@{#38980}
-
- 08 Aug, 2016 1 commit
-
-
adamk authored
%InitializeConstGlobal has been dead code since the demise of legacy const declarations. While getting rid of that call, also cleaned up and clarified the surrounding code in a variety of ways. R=neis@chromium.org Review-Url: https://codereview.chromium.org/2219223002 Cr-Commit-Position: refs/heads/master@{#38457}
-
- 02 Aug, 2016 2 commits
-
-
adamk authored
They may have once been different, but they're now redundant with each other. This simplifies both Context::Lookup and its callers. Review-Url: https://codereview.chromium.org/2200303002 Cr-Commit-Position: refs/heads/master@{#38261}
-
adamk authored
This was being allowed due to the use of BindingFlags instead of VariableMode to determine whether a looked-up binding was lexical. Because function declarations are hoisted, they never need hole checks, and so were being miscategorized as non-lexical. This patch augments Context::Lookup with a VariableMode out param, which allows this check to determine precisely whether the binding is lexical. BUG=v8:4454, v8:5256 Review-Url: https://codereview.chromium.org/2206483004 Cr-Commit-Position: refs/heads/master@{#38260}
-
- 01 Aug, 2016 1 commit
-
-
jochen authored
Also remove unnecessary includes of scopeinfo.h all over the place R=marja@chromium.org TBR=verwaest@chromium.org BUG= Review-Url: https://codereview.chromium.org/2197973002 Cr-Commit-Position: refs/heads/master@{#38204}
-
- 25 Jul, 2016 1 commit
-
-
jochen authored
R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2173403002 Cr-Commit-Position: refs/heads/master@{#38007}
-
- 13 Jul, 2016 1 commit
-
-
ishell authored
[ic] Initialize feedback slots for LoadGlobalIC in Runtime::kDeclareGlobals when possible to avoid misses. BUG=chromium:576312 Review-Url: https://codereview.chromium.org/2107193002 Cr-Commit-Position: refs/heads/master@{#37709}
-
- 28 Jun, 2016 2 commits
-
-
ishell authored
BUG=chromium:623912 Review-Url: https://codereview.chromium.org/2109603002 Cr-Commit-Position: refs/heads/master@{#37326}
-
neis authored
R=adamk@chromium.org BUG= Review-Url: https://codereview.chromium.org/2081733004 Cr-Commit-Position: refs/heads/master@{#37311}
-
- 21 Jun, 2016 1 commit
-
-
jwolfe authored
Reland of https://codereview.chromium.org/2048703002/ Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError (this caused a test262 failure.). However, the code `eval("function NaN() {}");` should actually throw a TypeError. This patch changes most cases of redeclaration errors from TypeError to SyntaxError. See the test mjsunit/regress/redeclaration-error-types for a thorough analysis with spec references. The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and ES#sec-evaldeclarationinstantiation BUG=v8:4955 LOG=y CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel R=adamk Review-Url: https://codereview.chromium.org/2086063002 Cr-Commit-Position: refs/heads/master@{#37156}
-
- 20 Jun, 2016 1 commit
-
-
adamk authored
Runtime_DeclareLookupSlot is used when generating code for var and function declarations originating in an eval. Over time, it's accumulated quite a bit of cruft, which this CL removes: - With legacy const gone, lookup slots never have any property attributes. - There was a bit signaling that the variable was from an eval, but that was redundant since DeclareLookupSlot is only used for eval. - Some Proxy-related code didn't make sense here. Its name was also not terribly clear: while "LookupSlot" is used in several places, this particular function is only used for declaring variables and functions inside sloppy eval. Renamed (and split into two) to make this clear for future archeologists. Also added various DCHECKs to check the assumptions being made. Review-Url: https://codereview.chromium.org/2061173002 Cr-Commit-Position: refs/heads/master@{#37111}
-
- 13 Jun, 2016 2 commits
-
-
littledan authored
Revert of change most cases of variable redeclaration from TypeError to SyntaxError (patchset #8 id:140001 of https://codereview.chromium.org/2048703002/ ) Reason for revert: This is going to break the LayoutTest inspector-protocol/console/console-let-const-with-api.html as seen in https://build.chromium.org/p/tryserver.v8/builders/v8_linux_blink_rel/builds/2247 . Please run this test manually, using instructions at https://www.chromium.org/developers/testing/webkit-layout-tests , and fix on the Chrome side if needed before resubmitting this patch. Original issue's description: > change most cases of variable redeclaration from TypeError to SyntaxError. > > Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError > (this caused a test262 failure.). However, the code `eval("function NaN() {}");` > should actually throw a TypeError. This patch changes most cases of > redeclaration errors from TypeError to SyntaxError. See the test > mjsunit/regress/redeclaration-error-types for a thorough analysis with spec > references. > > The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and > ES#sec-evaldeclarationinstantiation > > BUG=v8:4955 > LOG=y > > Committed: https://crrev.com/2b787561763d0f7e8dab698652715a742cf78291 > Cr-Commit-Position: refs/heads/master@{#36940} TBR=adamk@chromium.org,jwolfe@igalia.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4955 Review-Url: https://codereview.chromium.org/2064793002 Cr-Commit-Position: refs/heads/master@{#36941}
-
jwolfe authored
Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError (this caused a test262 failure.). However, the code `eval("function NaN() {}");` should actually throw a TypeError. This patch changes most cases of redeclaration errors from TypeError to SyntaxError. See the test mjsunit/regress/redeclaration-error-types for a thorough analysis with spec references. The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and ES#sec-evaldeclarationinstantiation BUG=v8:4955 LOG=y Review-Url: https://codereview.chromium.org/2048703002 Cr-Commit-Position: refs/heads/master@{#36940}
-
- 09 Jun, 2016 2 commits
-
-
adamk authored
Neither globals nor lookup slots can be hole-initialized anymore, thus removing some dead code from the code generators and runtime-scopes. Review-Url: https://codereview.chromium.org/2051073004 Cr-Commit-Position: refs/heads/master@{#36876}
-
mstarzinger authored
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed in a separate CL for all runtime modules at once. R=bmeurer@chromium.org BUG=v8:5066 Review-Url: https://codereview.chromium.org/2045193002 Cr-Commit-Position: refs/heads/master@{#36852}
-
- 06 Jun, 2016 1 commit
-
-
cbruni authored
Passing in the isolate and pointer compare the instnance against the corresponding constant is always faster than decoding the instance types. BUG= Review-Url: https://codereview.chromium.org/2028983002 Cr-Commit-Position: refs/heads/master@{#36744}
-
- 24 May, 2016 1 commit
-
-
yangguo authored
R=franzih@chromium.org Review-Url: https://codereview.chromium.org/2006673002 Cr-Commit-Position: refs/heads/master@{#36470}
-
- 13 May, 2016 1 commit
-
-
verwaest authored
Hidden prototypes are merely an implementation detail. Properties on an object + hidden prototype should look like properties on the object. Hence we should always perform a hidden prototype lookup. This CL removes the option to ignore hidden prototypes to avoid bugs that leak this implementation detail. Also, the only previously valid cases were either places were we knew we didn't have a hidden prototype; or because we knew we (in the optimizing compiler) would only handle properties from the non-hidden object.The first case is already handled by directly tagging whether a receiver has a hidden prototype. In the second case we can just filter out properties from hidden prototypes. Review-Url: https://codereview.chromium.org/1975763002 Cr-Commit-Position: refs/heads/master@{#36235}
-
- 11 May, 2016 1 commit
-
-
bmeurer authored
Make JSCreateArguments eliminatable, and remove the need for frame states on JSCreateArguments nodes being lowered to (optimized) stub calls. Only the runtime fallback needs a frame state, because in that case we need to ask the deoptimizer for arguments to inlined functions. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/1965013005 Cr-Commit-Position: refs/heads/master@{#36154}
-
- 19 Apr, 2016 1 commit
-
-
adamk authored
Now that all 'const' declarations are of the ES2015 variety, the only use of CONST_LEGACY is for function name bindings in sloppy mode named function expressions. This patch aims to delete all code meant to handle other cases, which mostly had to do with hole initialization/hole checks. Since function name bindings are initialized at entry to a function, it's impossible to ever observe one in an uninitialized state. To simplify the patch further, it removes the `IMPORT` VariableMode, as it's not likely to be needed (IMPORT is identical to CONST for the purpose of VariableMode). Review URL: https://codereview.chromium.org/1895973002 Cr-Commit-Position: refs/heads/master@{#35632}
-
- 17 Mar, 2016 1 commit
-
-
cbruni authored
HandleScopes in for-loops are rather expensive and pose a significant overhead to some builtin/runtime-functions. The FOR_WITH_HANDLE_SCOPE macro is used to only create a new HandleScope every 1024th iteration. BUG= Review URL: https://codereview.chromium.org/1785403002 Cr-Commit-Position: refs/heads/master@{#34856}
-
- 07 Mar, 2016 1 commit
-
-
verwaest authored
This avoids a minor unnecessary inefficiency (GetRoot) in setting up the LookupIterator. BUG= Review URL: https://codereview.chromium.org/1767123002 Cr-Commit-Position: refs/heads/master@{#34560}
-
- 01 Mar, 2016 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1731063007 Cr-Commit-Position: refs/heads/master@{#34398}
-
- 12 Feb, 2016 2 commits
-
-
bmeurer authored
This removes support for the %Arguments and %ArgumentsLength runtime entries and their intrinsic counterparts. If you need variable arguments in any builtin, either use (strict) arguments object or rest parameters, which are both compositional across inlining (in TurboFan), and not that much slower compared to the %_Arguments hackery. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1688163004 Cr-Commit-Position: refs/heads/master@{#33943}
-
bmeurer authored
The FastNewStrictArgumentsStub is very similar to the recently added FastNewRestParameterStub, it's actually almost a copy of it, except that it doesn't have the fast case we have for the empty rest parameter. This patch improves strict arguments in TurboFan and fullcodegen by up to 10x compared to the previous version. Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject for the in-object properties instead of having them as constants in the Heap class. Drive-by-fix: Use this stub and the FastNewRestParameterStub in the interpreter to avoid the runtime call overhead for strict arguments and rest parameter creation. R=jarin@chromium.org TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1693513002 Cr-Commit-Position: refs/heads/master@{#33925}
-
- 11 Feb, 2016 1 commit
-
-
bmeurer authored
Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof, %LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and %StoreLookupSlot_Strict runtime entry points and use them appropriately in the various compilers. This way we can finally drop the machine operators from the JS graph level completely in TurboFan. Also drop the funky JSLoadDynamic operator from TurboFan, which was by now just a small wrapper around the runtime call to %LoadLookupSlot. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1683103002 Cr-Commit-Position: refs/heads/master@{#33880}
-
- 08 Feb, 2016 1 commit
-
-
bmeurer authored
Replace the somewhat awkward RestParamAccessStub, which would always call into the runtime anyway with a proper FastNewRestParameterStub, which is basically based on the code that was already there for strict arguments object materialization. But for rest parameters we could optimize even further (leading to 8-10x improvements for functions with rest parameters), by fixing the internal formal parameter count: Every SharedFunctionInfo has a formal_parameter_count field, which specifies the number of formal parameters, and is used to decide whether we need to create an arguments adaptor frame when calling a function (i.e. if there's a mismatch between the actual and expected parameters). Previously the formal_parameter_count included the rest parameter, which was sort of unfortunate, as that meant that calling a function with only the non-rest parameters still required an arguments adaptor (plus some other oddities). Now with this CL we fix, so that we do no longer include the rest parameter in that count. Thereby checking for rest parameters is very efficient, as we only need to check whether there is an arguments adaptor frame, and if not create an empty array, otherwise check whether the arguments adaptor frame has more parameters than specified by the formal_parameter_count. The FastNewRestParameterStub is written in a way that it can be directly used by Ignition as well, and with some tweaks to the TurboFan backends and the CodeStubAssembler, we should be able to rewrite it as TurboFanCodeStub in the near future. Drive-by-fix: Refactor and unify the CreateArgumentsType which was different in TurboFan and Ignition; now we have a single enum class which is used in both TurboFan and Ignition. R=jarin@chromium.org, rmcilroy@chromium.org TBR=rossberg@chromium.org BUG=v8:2159 LOG=n Review URL: https://codereview.chromium.org/1676883002 Cr-Commit-Position: refs/heads/master@{#33809}
-
- 05 Feb, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
- 04 Feb, 2016 2 commits
-
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1667083002 Cr-Commit-Position: refs/heads/master@{#33737}
-
- 03 Feb, 2016 2 commits
-
-
neis authored
BUG=chromium:583260 LOG=n Review URL: https://codereview.chromium.org/1664683002 Cr-Commit-Position: refs/heads/master@{#33697}
-
bmeurer authored
We always call GetCallerArguments with 0 for prefix_argc, and so there's no use in having that parameter at all. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1662953002 Cr-Commit-Position: refs/heads/master@{#33694}
-