- 17 Aug, 2016 1 commit
-
-
rmcilroy authored
Now that all backends use the source position builder to record source positions, simplify the code line logging events to take a source position table on code creation. This means that the source position table builder no longer needs to access the isolate until the table is generated. This is required for off-thread bytecode generation. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2248673002 Cr-Commit-Position: refs/heads/master@{#38676}
-
- 12 Aug, 2016 1 commit
-
-
jkummerow authored
The hand-written KeyedLoadIC_Megamorphic stub didn't care about JSArray lengths, which made it lenient towards said lengths being wrong, but it will soon fix that bug and thereby become more strict. LiveEdit: factory->NewJSArray(capacity) doesn't set a length, so set it manually. RegExp: to avoid having to take care of array length updating in the RegExpExecStub, just use a JSObject instead. Review-Url: https://codereview.chromium.org/2244673002 Cr-Commit-Position: refs/heads/master@{#38624}
-
- 10 Aug, 2016 1 commit
-
-
mstarzinger authored
This adds the --ignition-preserve-bytecode flag which will preserve any existing bytecode, even if a tier-up to baseline code is performed. This is preparatory work in order to allow mixed stacks where bytecode and baseline code can be active at the same time. It also adds a {HasBaselineCode} predicate symmetric to the existing {HasBytecodeArray} predicate. Both predicates are independent and any combination of answers is valid. Further adaptation of the rest of the runtime will be done step-wise in follow-up changes. R=yangguo@chromium.org BUG=v8:5265 Review-Url: https://codereview.chromium.org/2224923003 Cr-Commit-Position: refs/heads/master@{#38540}
-
- 09 Aug, 2016 1 commit
-
-
yangguo authored
BUG=v8:5265 Review-Url: https://codereview.chromium.org/2218873002 Cr-Commit-Position: refs/heads/master@{#38482}
-
- 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}
-
- 28 Jul, 2016 1 commit
-
-
cbruni authored
This CL introduces a new fast flat instantiations cache for the first 1024 object templates. After that we fall back to the existing slower dictionary cache. Drive-by-fix: de-handlify and clean up some code in api-natives.cc BUG=chromium:630217 Review-Url: https://codereview.chromium.org/2170743003 Cr-Commit-Position: refs/heads/master@{#38146}
-
- 25 Jul, 2016 1 commit
-
-
nikolaos authored
This patch parametrizes AstTraversalVisitor by the actual subclass, in a similar way as AstVisitor is parametrized. This allows a subclass to, e.g., override the Visit method and still use the traversal mechanism. It also allows the subclass to override the specific visiting methods, without them being virtual. This patch also removes AstExpressionVisitor, subsuming its functionality in AstTraversalVisitor. R=adamk@chromium.org, verwaest@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2169833002 Cr-Commit-Position: refs/heads/master@{#37998}
-
- 30 Jun, 2016 1 commit
-
-
jgruber authored
Prior to this commit, calls to C++ builtins created standard exit frames, which are skipped when constructing JS stack traces. In order to show these calls on traces, we introduce a new builtin exit frame type. Builtin exit frames contain target and new.target on the stack and are not skipped during stack trace construction. BUG=v8:4815 R=bmeurer@chromium.org, yangguo@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a Review-Url: https://codereview.chromium.org/2090723005 Cr-Original-Commit-Position: refs/heads/master@{#37384} Cr-Commit-Position: refs/heads/master@{#37416}
-
- 29 Jun, 2016 3 commits
-
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2109613004 Cr-Commit-Position: refs/heads/master@{#37397}
-
bmeurer authored
Revert of [builtins] New frame type for exits to C++ builtins (patchset #5 id:80001 of https://codereview.chromium.org/2090723005/ ) Reason for revert: Looks like this breaks on nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/7626 Original issue's description: > [builtins] New frame type for exits to C++ builtins > > Prior to this commit, calls to C++ builtins created standard exit > frames, which are skipped when constructing JS stack traces. In order to > show these calls on traces, we introduce a new builtin exit frame type. > > Builtin exit frames contain target and new.target on the stack and are > not skipped during stack trace construction. > > BUG=v8:4815 > R=bmeurer@chromium.org, yangguo@chromium.org > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel > > Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a > Cr-Commit-Position: refs/heads/master@{#37384} TBR=yangguo@chromium.org,jgruber@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4815 Review-Url: https://codereview.chromium.org/2106113002 Cr-Commit-Position: refs/heads/master@{#37394}
-
jgruber authored
Prior to this commit, calls to C++ builtins created standard exit frames, which are skipped when constructing JS stack traces. In order to show these calls on traces, we introduce a new builtin exit frame type. Builtin exit frames contain target and new.target on the stack and are not skipped during stack trace construction. BUG=v8:4815 R=bmeurer@chromium.org, yangguo@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel Review-Url: https://codereview.chromium.org/2090723005 Cr-Commit-Position: refs/heads/master@{#37384}
-
- 28 Jun, 2016 1 commit
-
-
yangguo authored
R=bmeurer@chromium.org, jgruber@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2095893002 Cr-Commit-Position: refs/heads/master@{#37309}
-
- 20 Jun, 2016 1 commit
-
-
yangguo authored
When updating source positions, we recompute reloc info. Under the assumption that reloc info is appended to the code, we may or may not need to allocate a new code object. That assumption is no longer valid since 2010 (see r5020). R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2077363002 Cr-Commit-Position: refs/heads/master@{#37097}
-
- 15 Jun, 2016 1 commit
-
-
caitpotter88 authored
If an active generator is found on the stack (FUNCTION_BLOCKED_UNDER_GENERATOR), and the target function is not found on top of that generator, add the error. Based on test by wingo@igalia.com and littledan@chromium.org (https://codereview.chromium.org/2035643003/) LOG=N BUG=v8:4483 R=yangguo@chromium.org, littledan@chromium.org Review-Url: https://codereview.chromium.org/2058733002 Cr-Commit-Position: refs/heads/master@{#37000}
-
- 14 Jun, 2016 1 commit
-
-
mstarzinger authored
The pattern of how our source files are listed in GYP files changed, which in turn broke the parsing pattern that GCMole uses to gather a list of files to check. Only 'cctest' file were checked, 'src' files were being ignored. R=cbruni@chromium.org Review-Url: https://codereview.chromium.org/2065933002 Cr-Commit-Position: refs/heads/master@{#36962}
-
- 08 Jun, 2016 1 commit
-
-
mstarzinger authored
This changes the contract for the aforementioned API function to be more permissive and allow callers to call it with less restrictions. The new contract is: a) For so far un-compiled functions, the compiler is free to choose the backend according to other decision criteria. Debug code can hence be provided by either Ignition or FullCodegen. b) For compiled functions, the compiler will provide debug code within the same tier as existing code. For Ignition the generated code will be equivalent to the old one. For FullCodegen the code will contain debug information and debug break slots. Concretely this fixes an issue where generator or async functions might have been compiled with an unexpected backend, due to the fact that the API method in question was always providing FullCodegen code. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2044063002 Cr-Commit-Position: refs/heads/master@{#36808}
-
- 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}
-
- 31 May, 2016 1 commit
-
-
littledan authored
Async functions are built out of generators, but the SharedFunctionInfo returns false for is_generator. is_resumable is the broader query. This patch fixes many parts of V8 to refer to is_resumable as appropriate. One incidental change is to remove a check for generators extending classes. This is part of a general check for constructors being the only thing which can extend classes, so it is removed here and the error message for the general case is made more accurate. BUG=v8:4483 Review-Url: https://codereview.chromium.org/1996943002 Cr-Commit-Position: refs/heads/master@{#36621}
-
- 27 May, 2016 1 commit
-
-
mvstanton authored
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. BUG= Review-Url: https://codereview.chromium.org/1906823002 Cr-Commit-Position: refs/heads/master@{#36539}
-
- 18 May, 2016 1 commit
-
-
jgruber authored
This moves collection of function information from its previous spot in the standard compiler pipeline (GetSharedFunctionInfo() and CompileTopLevel()) to its new location in CompileForLiveEdit. Nesting information is reconstructed by traversing the AST. R=yangguo@chromium.org BUG= Review-Url: https://codereview.chromium.org/1971683002 Cr-Commit-Position: refs/heads/master@{#36306}
-
- 17 May, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:4765 Review-Url: https://codereview.chromium.org/1973213003 Cr-Commit-Position: refs/heads/master@{#36272}
-
- 13 May, 2016 2 commits
-
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:4765 Review-Url: https://codereview.chromium.org/1976933002 Cr-Commit-Position: refs/heads/master@{#36240}
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:4765 Review-Url: https://codereview.chromium.org/1968423002 Cr-Commit-Position: refs/heads/master@{#36237}
-
- 18 Apr, 2016 2 commits
-
-
mstarzinger authored
This makes sure that the Compiler::CompileForLiveEdit API function uses the common pipeline for top-level code. It ensures that a proper shared function info object is allocated before compilation is triggered. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1900613002 Cr-Commit-Position: refs/heads/master@{#35590}
-
yangguo authored
There were a couple of issues with it: - interpreter is not supported - the source position was just accidentally correct for full-codegen - the eval origin could have been cached Also fixes a few other places to use AbstractCode. R=mstarzinger@chromium.org Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d Cr-Commit-Position: refs/heads/master@{#35257} Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16 Cr-Commit-Position: refs/heads/master@{#35481} Review URL: https://codereview.chromium.org/1854713002 Cr-Commit-Position: refs/heads/master@{#35581}
-
- 14 Apr, 2016 2 commits
-
-
yangguo authored
Revert of Correctly annotate eval origin. (patchset #5 id:80001 of https://codereview.chromium.org/1854713002/ ) Reason for revert: performance impact Original issue's description: > Correctly annotate eval origin. > > There were a couple of issues with it: > - interpreter is not supported > - the source position was just accidentally correct for full-codegen > - the eval origin could have been cached > > Also fixes a few other places to use AbstractCode. > > R=mstarzinger@chromium.org > > Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d > Cr-Commit-Position: refs/heads/master@{#35257} > > Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16 > Cr-Commit-Position: refs/heads/master@{#35481} TBR=mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1888013002 Cr-Commit-Position: refs/heads/master@{#35491}
-
yangguo authored
There were a couple of issues with it: - interpreter is not supported - the source position was just accidentally correct for full-codegen - the eval origin could have been cached Also fixes a few other places to use AbstractCode. R=mstarzinger@chromium.org Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d Cr-Commit-Position: refs/heads/master@{#35257} Review URL: https://codereview.chromium.org/1854713002 Cr-Commit-Position: refs/heads/master@{#35481}
-
- 05 Apr, 2016 2 commits
-
-
machenbach authored
Revert of Correctly annotate eval origin. (patchset #4 id:60001 of https://codereview.chromium.org/1854713002/ ) Reason for revert: [Sheriff] Crashes a layout test: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/5855 Original issue's description: > Correctly annotate eval origin. > > There were a couple of issues with it: > - interpreter is not supported > - the source position was just accidentally correct for full-codegen > - the eval origin could have been cached > > Also fixes a few other places to use AbstractCode. > > R=mstarzinger@chromium.org > > Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d > Cr-Commit-Position: refs/heads/master@{#35257} TBR=mstarzinger@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1858773004 Cr-Commit-Position: refs/heads/master@{#35260}
-
yangguo authored
There were a couple of issues with it: - interpreter is not supported - the source position was just accidentally correct for full-codegen - the eval origin could have been cached Also fixes a few other places to use AbstractCode. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1854713002 Cr-Commit-Position: refs/heads/master@{#35257}
-
- 01 Apr, 2016 1 commit
-
-
jochen authored
We expect that the majority of malloc'd memory held by V8 is allocated in Zone objects. Introduce an Allocator class that is used by Zones to manage memory, and allows for querying the current usage. BUG=none R=titzer@chromium.org,bmeurer@chromium.org,jarin@chromium.org LOG=n TBR=rossberg@chromium.org Review URL: https://codereview.chromium.org/1847543002 Cr-Commit-Position: refs/heads/master@{#35196}
-
- 08 Mar, 2016 2 commits
-
-
verwaest authored
Also move GetProperty with string-name to JSReceiver BUG= Review URL: https://codereview.chromium.org/1775973002 Cr-Commit-Position: refs/heads/master@{#34596}
-
danno authored
Before this CL, various code stubs used different techniques for marking their frames to enable stack-crawling and other access to data in the frame. All of them were based on a abuse of the "standard" frame representation, e.g. storing the a context pointer immediately below the frame's fp, and a function pointer after that. Although functional, this approach tends to make stubs and builtins do an awkward, unnecessary dance to appear like standard frames, even if they have nothing to do with JavaScript execution. This CL attempts to improve this by: * Ensuring that there are only two fundamentally different types of frames, a "standard" frame and a "typed" frame. Standard frames, as before, contain both a context and function pointer. Typed frames contain only a minimum of a smi marker in the position immediately below the fp where the context is in standard frames. * Only interpreted, full codegen, and optimized Crankshaft and TurboFan JavaScript frames use the "standard" format. All other frames use the type frame format with an explicit marker. * Typed frames can contain one or more values below the type marker. There is new magic macro machinery in frames.h that simplifies defining the offsets of these fields in typed frames. * A new flag in the CallDescriptor enables specifying whether a frame is a standard frame or a typed frame. Secondary register location spilling is now only enabled for standard frames. * A zillion places in the code have been updated to deal with the fact that most code stubs and internal frames use the typed frame format. This includes changes in the deoptimizer, debugger, and liveedit. * StandardFrameConstants::kMarkerOffset is deprecated, (CommonFrameConstants::kContextOrFrameTypeOffset and StandardFrameConstants::kFrameOffset are now used in its stead). LOG=N Review URL: https://codereview.chromium.org/1696043002 Cr-Commit-Position: refs/heads/master@{#34571}
-
- 25 Feb, 2016 1 commit
-
-
jkummerow authored
Mostly by avoiding unnecessary Handle/HandleScope creation, "length" property lookups, and length conversions. This yields about 60% speedup on the microbenchmark I tested with. Note that the C++ builtin is the middle performance tier of three, so not every Array.push use case will be affected by this patch. Review URL: https://codereview.chromium.org/1716833002 Cr-Commit-Position: refs/heads/master@{#34268}
-
- 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 1 commit
-
-
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}
-
- 29 Jan, 2016 1 commit
-
-
jkummerow authored
String wrappers (new String("foo")) are special objects: their string characters are accessed like elements, and they also have an elements backing store. This used to require a bunch of explicit checks like: if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) { /* Handle string characters */ } // Handle regular elements (for string wrappers and other objects) obj->GetElementsAccessor()->Whatever(...); This CL introduces new ElementsKinds for string wrapper objects (one for fast elements, one for dictionary elements), which allow folding the special-casing into new StringWrapperElementsAccessors. No observable change in behavior is intended. Review URL: https://codereview.chromium.org/1612323003 Cr-Commit-Position: refs/heads/master@{#33616}
-
- 27 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > 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... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@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/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) 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... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
- 26 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > 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... > > TBR=hpayer@chromium.org > > BUG= > > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # 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/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
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... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-