- 04 Mar, 2017 1 commit
-
-
vabr authored
BUG=v8:6026 Review-Url: https://codereview.chromium.org/2728463006 Cr-Commit-Position: refs/heads/master@{#43600}
-
- 21 Feb, 2017 1 commit
-
-
bjaideep authored
Port fd596007 Original Commit Message: Use an opaque format for the frame type marker on the stack, where the marker is simply shifted left by 1 instead of being a Smi. This allows us to generate simpler code for frame initialisation, as we can push a smaller value, decreasing the prologue by 4 bytes and one instruction. R=leszeks@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2709483007 Cr-Commit-Position: refs/heads/master@{#43356}
-
- 16 Feb, 2017 1 commit
-
-
bjaideep authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2697713006 Cr-Commit-Position: refs/heads/master@{#43227}
-
- 15 Feb, 2017 1 commit
-
-
Peter Marshall authored
The mips64 implementation always ended up in the slowpath due to some loads that were the wrong width, so that is also fixed here. BUG=v8:5974 Change-Id: Ie448a1fab5b7fca87597c5a1bf75443864e30c28 Reviewed-on: https://chromium-review.googlesource.com/443247 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#43222}
-
- 14 Feb, 2017 1 commit
-
-
vabr authored
If the Reflect.construct receives an argument expected to be a constructor, and the argument is not a constructor, V8 currently declares that Reflect.construct is not a function. It should instead say that the offending argument is not a constructor. This is the case for all ports of builtins (Builtins::Generate_ReflectConstruct). All of them make an attempt to at least pass the right argument to the TypeError parametrised message, calling out the offending Reflect.construct argument. However, Runtime::kThrowCalledNonCallable extracts the callsite from those arguments, discarding the precise information. This CL adds Runtime::kNotConstructor, which reports the arguments passed to it, and the CL also modifies the ports of builtins to make use of Runtime::kNotConstructor BUG=v8:5671 Review-Url: https://codereview.chromium.org/2688393003 Cr-Commit-Position: refs/heads/master@{#43182}
-
- 13 Feb, 2017 1 commit
-
-
bjaideep authored
Port 6ee0b6ce Original Commit Message: This adds support for deoptimizing into the JSConstructStub after the receiver instantiation but before the actual constructor invocation. Such a deoptimization point is needed for cases where instantiation might be observed (e.g. when new.target is a proxy) and hence might trigger a deopt. We use this new deoptimization point for the "after" frame-state the inliner attaches to {JSCreate} nodes being inserted when constructor calls are being inlined. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5638 LOG=N Review-Url: https://codereview.chromium.org/2690213002 Cr-Commit-Position: refs/heads/master@{#43171}
-
- 07 Feb, 2017 1 commit
-
-
ishell@chromium.org authored
... and TypeFeedbackMetadata to FeedbackMetadata. BUG= Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c Reviewed-on: https://chromium-review.googlesource.com/439244 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#42999}
-
- 06 Feb, 2017 1 commit
-
-
mvstanton authored
TypeFeedbackVectors are strongly rooted by a closure. However, in modern JavaScript closures are created and abandoned more freely. An important closure may not be present in the root-set at time of garbage collection, even though we've cached optimized code and use it regularly. For example, consider leaf functions in an event dispatching system. They may well be "hot," but tragically non-present when we collect the heap. Until now, we've relied on a weak root to cache the feedback vector in this case. Since there is no way to signal intent or relative importance, this weak root is as susceptible to clearing as any other weak root at garbage collection time. Meanwhile, the feedback vector has become more important. All of our ICs store their data there. Literal and regex boilerplates are stored there. If we lose the vector, then we not only lose optimized code built from it, we also lose the very feedback which allowed us to create that optimized code. Therefore it's vital to express that dependency through the root set. This CL does this by creating a strong link to a feedback vector at the instantiation site of the function closure. This instantiation site is in the code and feedback vector of the outer closure. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2674593003 Cr-Commit-Position: refs/heads/master@{#42953}
-
- 01 Feb, 2017 1 commit
-
-
bjaideep authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2668303002 Cr-Commit-Position: refs/heads/master@{#42864}
-
- 30 Jan, 2017 2 commits
-
-
bjaideep authored
Port 93f05b64 Original Commit Message: They have the same lifetime. It's a match! Both structures are native context dependent and dealt with (creation, clearing, gathering feedback) at the same time. By treating the spaces used for literal boilerplates as feedback vector slots, we no longer have to keep track of the materialized literal count elsewhere. A follow-on CL removes even more parser infrastructure related to this count. R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5456 LOG=N Review-Url: https://codereview.chromium.org/2659413002 Cr-Commit-Position: refs/heads/master@{#42778}
-
petermarshall authored
We need it to be a PropertyCell so that we can list it as a dependency for optimised code. Also drive-by clean up some variable names in src/isolate-inl.h. BUG=v8:5895 Review-Url: https://codereview.chromium.org/2658573008 Cr-Commit-Position: refs/heads/master@{#42764}
-
- 27 Jan, 2017 1 commit
-
-
bjaideep authored
Port 69747e26 Original Commit Message: We turn a JSCallFunction node for f.apply(receiver, arguments) into a JSCallForwardVarargs node, when the arguments refers to the arguments of the outermost optimized code object, i.e. not an inlined arguments, and the apply method refers to Function.prototype.apply, and there's no other user of arguments except in frame states. We also replace the arguments node in the graph with a marker for the Deoptimizer similar to Crankshaft to make sure we don't materialize unused arguments just for the sake of deoptimization. We plan to replace this with a saner EscapeAnalysis based solution soon. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5267,v8:5726 LOG=N Review-Url: https://codereview.chromium.org/2656363002 Cr-Commit-Position: refs/heads/master@{#42745}
-
- 26 Jan, 2017 1 commit
-
-
bjaideep authored
Port f9367847 Port bf782ec5 Original Commit Message: We can share almost all of the architecture-specific builtin code with super-call-with-spread. Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store. R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5511 LOG=N Review-Url: https://codereview.chromium.org/2655043004 Cr-Commit-Position: refs/heads/master@{#42708}
-
- 24 Jan, 2017 1 commit
-
-
petermarshall authored
We can share almost all of the architecture-specific builtin code with super-call-with-spread. Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2649143002 Cr-Commit-Position: refs/heads/master@{#42632}
-
- 23 Jan, 2017 1 commit
-
-
bjaideep authored
Port 3a9152ec Original Commit Message: We are planning to add a few more debugger related bits, and are running out of compiler hints bits. The new bit field is going to be part of the debug info struct. If the debug info is not available, we store the bit field in its place on the shared function info. R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2653673002 Cr-Commit-Position: refs/heads/master@{#42608}
-
- 20 Jan, 2017 1 commit
-
-
petermarshall authored
FAST_DOUBLE_ELEMENTS and FAST_HOLEY_DOUBLE_ELEMENTS kinds should both be handled by the runtime. Review-Url: https://codereview.chromium.org/2644643011 Cr-Commit-Position: refs/heads/master@{#42561}
-
- 19 Jan, 2017 3 commits
-
-
mvstanton authored
GC performance issues need to be addressed first. TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:5456 Review-Url: https://codereview.chromium.org/2642743002 Cr-Original-Commit-Position: refs/heads/master@{#42495} Committed: https://chromium.googlesource.com/v8/v8/+/7803aa1ffb2f835c5f317ed2a097390d53e52567 Review-Url: https://codereview.chromium.org/2642743002 Cr-Commit-Position: refs/heads/master@{#42517}
-
machenbach authored
Revert of Revert [TypeFeedbackVector] Root literal arrays in function literal slots (patchset #2 id:20001 of https://codereview.chromium.org/2642743002/ ) Reason for revert: Breaks nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/13802 Original issue's description: > Revert [TypeFeedbackVector] Root literal arrays in function literal slots > > GC performance issues need to be addressed first. > > TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org > BUG=v8:5456 > > Review-Url: https://codereview.chromium.org/2642743002 > Cr-Commit-Position: refs/heads/master@{#42495} > Committed: https://chromium.googlesource.com/v8/v8/+/7803aa1ffb2f835c5f317ed2a097390d53e52567 TBR=mvstanton@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5456 Review-Url: https://codereview.chromium.org/2642933003 Cr-Commit-Position: refs/heads/master@{#42496}
-
mvstanton authored
GC performance issues need to be addressed first. TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:5456 Review-Url: https://codereview.chromium.org/2642743002 Cr-Commit-Position: refs/heads/master@{#42495}
-
- 18 Jan, 2017 3 commits
-
-
bjaideep authored
Port 0b8200c7 R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5659 LOG=N Review-Url: https://codereview.chromium.org/2645683002 Cr-Commit-Position: refs/heads/master@{#42482}
-
mvstanton authored
Due to outstanding performance issues, it's safer to revert these changes. Revert "PPC/s390: [TypeFeedbackVector] DeclareGlobals needs a literals array" Revert "[TypeFeedbackVector] DeclareGlobals needs a literals array" Revert "PPC/s390: [builtins] CompileLazy bailed out to the runtime entirely too often." Revert "[builtins] CompileLazy bailed out to the runtime entirely too often." Another CL is to follow that removes the main part of this work (after that revert, performance regressions should disappear. TBR=mstarzinger@chromium.org, leszeks@chromium.org, bmeurer@chromium.org BUG=680637 Review-Url: https://codereview.chromium.org/2645543002 Cr-Commit-Position: refs/heads/master@{#42456}
-
petermarshall authored
BUG=v8:5659 Review-Url: https://codereview.chromium.org/2571563004 Cr-Commit-Position: refs/heads/master@{#42444}
-
- 17 Jan, 2017 2 commits
-
-
bjaideep authored
Port 743fdb25 Original Commit Message: This is just a bug. CompileLazy knows how to look in the SharedFunctionInfo for code (or bytecode, essentially) if it finds nothing in the OptimizedCodeMap. Ensure that behavior. R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=681543 LOG=N Review-Url: https://codereview.chromium.org/2641473002 Cr-Commit-Position: refs/heads/master@{#42422}
-
neis authored
The resume trampolin used to call the generator function with the context of the last suspension rather than the closure's context. While that was fine for Ignition, Turbofan got utterly confused. With this CL, the resume trampolin always passes in the closure's context (like in the very first call of the generator function). The generator function itself then restores its previously current context by reading it from the generator object and doing a PushContext. BUG=chromium:681171 Review-Url: https://codereview.chromium.org/2639533002 Cr-Commit-Position: refs/heads/master@{#42407}
-
- 12 Jan, 2017 2 commits
-
-
bjaideep authored
Port aa75904e R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5821 LOG=N Review-Url: https://codereview.chromium.org/2632513002 Cr-Commit-Position: refs/heads/master@{#42292}
-
bjaideep authored
Port b8294aaa Original Commit Message: Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5456 LOG=N Review-Url: https://codereview.chromium.org/2626263002 Cr-Commit-Position: refs/heads/master@{#42280}
-
- 03 Jan, 2017 1 commit
-
-
bjaideep authored
Port 72c37076 Original Commit Message: Currently the CompileLazy builtin checks the SFI expliciltly for FCG code. This means if the SFI has bytecode we have to go through to the runtime to install the interpreter entry trampoline into the JSFunction object. Modify the builtin to always put the SFI code object into the JSFunction unless it's the lazy compile stub on the SFI as well. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:4380 LOG=N Review-Url: https://codereview.chromium.org/2602383003 Cr-Commit-Position: refs/heads/master@{#42046}
-
- 29 Dec, 2016 1 commit
-
-
bjaideep authored
Port 5b02a98b Original Commit Message: In the process, convert from a code stub into a builtin. R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2601243003 Cr-Commit-Position: refs/heads/master@{#41992}
-
- 27 Dec, 2016 1 commit
-
-
bjaideep authored
Reason for revert: Original CL was reverted, https://codereview.chromium.org/2597163002 Original issue's description: > PPC/s390: [TypeFeedbackVector] Root literal arrays in function literals slots > > Port 93df0940 > > Original Commit Message: > > Literal arrays and feedback vectors for a function can be garbage > collected if we don't have a rooted closure for the function, which > happens often. It's expensive to come back from this (recreating > boilerplates and gathering feedback again), and the cost is > disproportionate if the function was inlined into optimized code. > > To guard against losing these arrays when we need them, we'll now > create literal arrays when creating the feedback vector for the outer > closure, and root them strongly in that vector. > > R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com > BUG=v8:5456 > LOG=N > > Review-Url: https://codereview.chromium.org/2592043003 > Cr-Commit-Position: refs/heads/master@{#41898} > Committed: https://chromium.googlesource.com/v8/v8/+/19aa7a20b0c39ea9ef81d6e021863183732f82c0 R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5456 LOG=N Review-Url: https://codereview.chromium.org/2601793002 Cr-Commit-Position: refs/heads/master@{#41966}
-
- 21 Dec, 2016 1 commit
-
-
bjaideep authored
Port 93df0940 Original Commit Message: Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5456 LOG=N Review-Url: https://codereview.chromium.org/2592043003 Cr-Commit-Position: refs/heads/master@{#41898}
-
- 10 Dec, 2016 1 commit
-
-
bjaideep authored
Port d4f01b8a Original Commit Message: Add fast paths for holey smi and object arrays to Function.prototype.apply, Reflect.apply and Reflect.construct. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2566793002 Cr-Commit-Position: refs/heads/master@{#41626}
-
- 07 Dec, 2016 1 commit
-
-
bjaideep authored
Port 378b6b22 Original Commit Message: Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2557113002 Cr-Commit-Position: refs/heads/master@{#41562}
-
- 29 Nov, 2016 2 commits
-
-
rmcilroy authored
Adds a bytecode_age field to BytecodeArray objects. This is incremented each time the bytecode array is marked by GC, and reset to zero if the bytecode is executed. This is used to enable the CompilationCache for interpreted functions, where Interpreted entries are evicted once the bytecode becomes old. BUG=chromium:666275,v8:4680 Review-Url: https://codereview.chromium.org/2534763003 Cr-Commit-Position: refs/heads/master@{#41356}
-
rmcilroy authored
MarkingParity was used to avoid performing an operation on an object if it was marked multiple times. We no longer mark things multiple times, so this concept is no longer required. BUG=chromium:666275 Review-Url: https://codereview.chromium.org/2529173002 Cr-Commit-Position: refs/heads/master@{#41354}
-
- 21 Nov, 2016 1 commit
-
-
mstarzinger authored
This removes the deprecated generator support for resumable functions from {FullCodeGenerator}. The existing {AstNumbering} heuristic already triggers Ignition for most resumable functions, with this change we make said heuristic a hard choice and remove the deprecated code. This also has the advantage that any suspended {JSGeneratorObject} instance on the heap is guaranteed to have code based on a bytecode array. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2504223002 Cr-Commit-Position: refs/heads/master@{#41135}
-
- 10 Nov, 2016 1 commit
-
-
bjaideep authored
Port 93c65952 Original commit message: This changes {FrameState} nodes modeling "after" states to use bytecode offsets pointing to the deoptimizing bytecode. This is in sync with the normal execution, as the bytecode offset is advanced after operations complete in regular bytecode handlers. The change is necessary to ensure lazy deoptimized frames contain an accurate bytecode offset while they are on the stack. Such frames can be inspected by various stack walks. The continuation builtin will advance the bytecode offset upon return. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2486393005 Cr-Commit-Position: refs/heads/master@{#40898}
-
- 04 Nov, 2016 1 commit
-
-
mstarzinger authored
This removes the deprecated flag in question which has been enabled by default a while ago. All components can by now deal with activations of a single function being mixed between Ignition and other compilers. The maintenance overhead to support a mode that clears bytecode is no longer warranted. R=rmcilroy@chromium.org BUG=v8:4280 Review-Url: https://codereview.chromium.org/2475203003 Cr-Commit-Position: refs/heads/master@{#40776}
-
- 27 Oct, 2016 1 commit
-
-
leszeks authored
Reuses (and renames) the SFI "mark for optimization" flag to also permit marking for baseline recompilation. The flag now represents a "tier up" request, and CompileLazy can get baseline code as well as optimized code. BUG=v8:5512 Review-Url: https://codereview.chromium.org/2448933002 Cr-Commit-Position: refs/heads/master@{#40612}
-
- 21 Oct, 2016 1 commit
-
-
leszeks authored
The current method of marking functions for optimization, which replaces the JSFunction's code object with one that triggers optimization, would never allow unnamed functions to be optimized. This is an issue for a style of programming which heavily relies on passing around closures. This patch sets a bit on the SharedFunctionInfo when a JSFunction is marked. When another JSFunction referring to the same SharedFunctionInfo is lazily compiled, it immediately triggers a non-concurrent optimize. BUG=v8:5512 Review-Url: https://chromiumcodereview.appspot.com/2437043002 Cr-Commit-Position: refs/heads/master@{#40506}
-
- 19 Oct, 2016 1 commit
-
-
ziyang authored
Port 77419488 Original commit message: This slot is completely unused and always undefined anyways, so there's no need to maintain the slot during object construction. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= Review-Url: https://chromiumcodereview.appspot.com/2429983002 Cr-Commit-Position: refs/heads/master@{#40441}
-