This removes --harmony-completion, --harmony-concat-spreadable, and
--harmony-tolength and moves the appropriate tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1667453002
Cr-Commit-Position: refs/heads/master@{#33712}
This patch ships the first part of RegExp subclassing--defining
Symbol.{match,replace,search,split}, but keeping their original
definitions which are restricted to a RegExp receiver and do not
call out to the core 'exec' method. This is being shipped separately
because the two sets of extension points are separate features with
separate functionality. The amount of behavior which is held behind
the flag is very small, just exposing the symbols as properties of
Symbol--the behavior that the String methods call out to these Symbol
properties has already been shipping unflagged.
R=yangguo@chromium.org
BUG=v8:4305,v8:4343,v8:4344,v8:4345
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1652793002
Cr-Commit-Position: refs/heads/master@{#33629}
The body of a generator function can now refer to the generator's input value via a new
"function.sent" expression. We extend the proposal at
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
in the obvious way to also apply to GeneratorResumeAbrupt.
This will enable us to desugar yield*.
The new syntax is behind a new --harmony-function-sent flag.
BUG=v8:4700
LOG=n
Review URL: https://codereview.chromium.org/1620253003
Cr-Commit-Position: refs/heads/master@{#33574}
This patch stages the first part of RegExp subclassing--defining
Symbol.{match,replace,search,split}, but keeping their original
definitions which are restricted to a RegExp receiver and do not
call out to the core 'exec' method. This is being staged separately
because the two sets of extension points are separate features with
separate functionality. The amount of behavior which is held behind
the flag is very small, just exposing the symbols as properties of
Symbol--the behavior that the String methods call out to these Symbol
properties has already been shipping unflagged.
R=yangguo@chromium.org
BUG=v8:4305,v8:4343,v8:4344,v8:4345
LOG=Y
Review URL: https://codereview.chromium.org/1637703003
Cr-Commit-Position: refs/heads/master@{#33534}
- Remove semispace target capacity: It's unused and adds some unneeded
complexity
- Enforcing decl order for SemiSpace
- Move forward declarations in spaces.h to top
- Add all members to default constructor
BUG=chromium:581076
LOG=N
Review URL: https://codereview.chromium.org/1631713002
Cr-Commit-Position: refs/heads/master@{#33515}
This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.
Tail calling can be enabled by --harmony-tailcalls flag.
BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1609893003
Cr-Commit-Position: refs/heads/master@{#33509}
The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1631593003
Cr-Commit-Position: refs/heads/master@{#33494}
In d8, run with --runtime-call-stats and it will output the stats when d8 finishes.
In Chrome, run the following: (only on trusted code, this punches *massive* security hole into Chrome)
chrome --js-flags="--runtime-call-stats --allow-natives-syntax"
To get the stats in the console, just run
console.log(%GetAndResetRuntimeCallStats());
To output stats every second:
setInterval(function() { console.log(%GetAndResetRuntimeCallStats()); }, 1000)
Review URL: https://codereview.chromium.org/1615943002
Cr-Commit-Position: refs/heads/master@{#33462}
Motivated by finding a bug in a larger module, this CL adds the ability
to dump out a byte-by-byte, nested view of the decoded AST. This
byte-by-byte output uses the opcode enum to make it readable, but is
suitable for pasting into a byte[] in C or JS and thus making a regression
test.
Also fix a bug; the case of running out of registers for indirect calls.
R=ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1616973004
Cr-Commit-Position: refs/heads/master@{#33442}
This removes the above flag definition. The flag is no longer needed as
the default implementation is more than capable of faking presence of
handling of try-catch and try-finally constructs by now.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1603063003
Cr-Commit-Position: refs/heads/master@{#33402}
Now that we support eval in Ignition, remove the fallback for eval checks
and make the flag only fallback on catch blocks.
BUG=v8:4280,v8:4676
LOG=N
Review URL: https://codereview.chromium.org/1595223004
Cr-Commit-Position: refs/heads/master@{#33384}
This patch moves the semantics of 'const' in sloppy mode to match those
in strict mode, that is, const makes lexical (let-like) bindings, must
have an initializer, and does not create properties of the global object.
R=adamk
LOG=Y
BUG=v8:3305
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1571873004
Cr-Commit-Position: refs/heads/master@{#33218}
Reason for revert:
Crash fixed by https://codereview.chromium.org/1564923007
Original issue's description:
> Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7 id:120001 of https://codereview.chromium.org/1551443002/ )
>
> Reason for revert:
> Causes frequent crashes in Canary: chromium:537816
>
> Original issue's description:
> > Ship ES2015 sloppy-mode function hoisting, let, class
> >
> > This patch doesn't ship all features of ES2015 variable/scoping
> > changes, notably omitting the removal of legacy const. I think
> > function hoisting, let and class in sloppy mode can stand to
> > themselves as a package, and the legacy const change is much
> > riskier and more likely to be reverted, so my intention is to
> > pursue those as a separate, follow-on patch.
> >
> > R=adamk@chromium.org
> > BUG=v8:4285,v8:3305
> > LOG=Y
> > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> >
> > Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> > Cr-Commit-Position: refs/heads/master@{#33133}
>
> TBR=adamk@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:4285,v8:3305,chromium:537816
> LOG=Y
>
> Committed: https://crrev.com/adac5956c6216056a211cfaa460a00ac1500d8f8
> Cr-Commit-Position: refs/heads/master@{#33162}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4285,v8:3305,chromium:537816
Review URL: https://codereview.chromium.org/1571793002
Cr-Commit-Position: refs/heads/master@{#33189}
Reason for revert:
Causes frequent crashes in Canary: chromium:537816
Original issue's description:
> Ship ES2015 sloppy-mode function hoisting, let, class
>
> This patch doesn't ship all features of ES2015 variable/scoping
> changes, notably omitting the removal of legacy const. I think
> function hoisting, let and class in sloppy mode can stand to
> themselves as a package, and the legacy const change is much
> riskier and more likely to be reverted, so my intention is to
> pursue those as a separate, follow-on patch.
>
> R=adamk@chromium.org
> BUG=v8:4285,v8:3305
> LOG=Y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> Cr-Commit-Position: refs/heads/master@{#33133}
TBR=adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4285,v8:3305,chromium:537816
LOG=Y
Review URL: https://codereview.chromium.org/1565263002
Cr-Commit-Position: refs/heads/master@{#33162}
This patch doesn't ship all features of ES2015 variable/scoping
changes, notably omitting the removal of legacy const. I think
function hoisting, let and class in sloppy mode can stand to
themselves as a package, and the legacy const change is much
riskier and more likely to be reverted, so my intention is to
pursue those as a separate, follow-on patch.
R=adamk@chromium.org
BUG=v8:4285,v8:3305
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1551443002
Cr-Commit-Position: refs/heads/master@{#33133}
This patch adds the basis for subclassing TypedArrays, Arrays and
ArrayBuffers through the @@species hook, added in ES2015. This is
the first patch in a series. This patch simply defines the
@@species Symbol and installs it on the appropriate constructors.
The behavior is guarded behind the --harmony-species flag.
R=cbruni
BUG=v8:4093
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
TBR=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1558543002
Cr-Commit-Position: refs/heads/master@{#33095}
Adds --turbo to the set of flags run with ignition (making the
configuration pure Ignition+TurboFan except for fallbacks to
full-codegen for catch / eval). Also changes the default
--ignition-filter to allow everything, rather than omit everything.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1537433003
Cr-Commit-Position: refs/heads/master@{#33090}
Essentially a revert of https://codereview.chromium.org/1346013005 but
preserving the refactorings in elements.cc which happened in the mean time.
drive-by-fix: pass isolate as argument to more functions in elements.cc.
BUG=v8:4606
LOG=y
Review URL: https://codereview.chromium.org/1543563002
Cr-Commit-Position: refs/heads/master@{#33023}
Add an internal field to each wasm function to keep a reference to the module. (So the GC can do the right thing when you only hold references to wasm functions but not the module).
Use Realloc carefully, to avoid copying from out of bounds.
Make snprintf use platform independent.
Don't disconnect external arraybuffers provided for the heap.
R=ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1531243003
Cr-Commit-Position: refs/heads/master@{#32951}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
Cr-Commit-Position: refs/heads/master@{#32841}
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32857}
Turning it off broke both the trace viewer and using the devtools
to connect to an earlier version of Chrome running on another device.
BUG=chromium:552100, chromium:569417, chromium:569647
TBR=rossberg@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1521993004 .
Cr-Commit-Position: refs/heads/master@{#32850}
Reason for revert:
[Sheriff] Layout test changes.
Original issue's description:
> [debugger] debug-evaluate should not not modify local values.
>
> Debug evaluate no longer writes back changes to the replicated
> context chain to the original after execution. Changes to the
> global object or script contexts still stick. Calling functions
> that bind to the original context chain also have their expected
> side effects.
>
> As far as I can tell, DevTools is not interested in modifying
> local variable values. Modifying global variable values still
> works as expected. However, I have not yet removed the old
> implementation, but merely keep it behind a flag.
>
> R=mstarzinger@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
> Cr-Commit-Position: refs/heads/master@{#32841}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1526553003
Cr-Commit-Position: refs/heads/master@{#32845}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32841}
This is behind the --harmony-function-name flag, currently disabled.
With the flag enabled, we now pass the relevant tests in
language/statements/*/fn-name-*.
BUG=v8:3699
LOG=y
Review URL: https://codereview.chromium.org/1518873004
Cr-Commit-Position: refs/heads/master@{#32817}
This patch removes Promise functions and methods which are absent
from the ES2015 specification when the --es-staging flag is on.
The patch is being relanded after being reverted due to an
unrelated bug. This version is slightly different as promise_chain
is installed on the context regardless of the flag value, so that
the Promise::Chain API continues to work until it is deprecated.
BUG=v8:3237
R=rossberg
LOG=Y
Review URL: https://codereview.chromium.org/1513873002
Cr-Commit-Position: refs/heads/master@{#32772}
This adds a runtime flag that controls whether the WASM object is
exposed to JavaScript. While currently guarded by the V8_WASM build-time
flag, after landing in V8 the build-time flag will be removed, leaving
only this new runtime flag.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1507623002
Cr-Commit-Position: refs/heads/master@{#32657}
Attempt #<really big number>
Parses, and lazily rewrites Destructuring Assignment expressions. The rewriting strategy involves inserting a placeholder RewritableAssignmentExpression into the AST, whose content expression can be completely rewritten at a later time.
Lazy rewriting ensures that errors do not occur due to eagerly rewriting nodes which form part of a binding pattern, thus breaking the meaning of the pattern --- or by eagerly rewriting ambiguous constructs that are not immediately known
BUG=v8:811
LOG=Y
R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1309813007
Cr-Commit-Position: refs/heads/master@{#32623}
This is the first part of escape analysis for turbofan.
At the moment, there is no deopt support, and support
for loops is partial (only binary Phis are handled).
The CL includes 4 unittests.
There are also 8 new mjsunit tests, some of which are
skiped as they require features not yet implemented.
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1457683003
Cr-Commit-Position: refs/heads/master@{#32498}
Also fix CheckConflictingVarDeclarations() to properly handle
legacy const bindings. Without that change enabling the flag
causes code like:
function f() { const x; var x; }
to throw an early error, rather than wait to throw the error
until f is invoked.
The previous patch ran into problems with the fuzzer; that crash was fixed
(with test coverage added) in https://crrev.com/ceb92ebfdfb561d71038793c02b42aa973f55ec4
BUG=v8:811
LOG=y
TBR=rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1473243006
Cr-Commit-Position: refs/heads/master@{#32306}
Some highlights of this CL:
* Refactor the mutable state out of Frame into FrameAccessState,
which is maintained and updated during code generation to
record whether sp- or fp-based frame access is currently active
and how deep the stack on top of the frame is.
* The operand resultion in linkage.cc now uses FrameAccessState
to determine how to generate frame-accessing operands.
* Update all platforms to accurately track additionally pushed
stack slots (e.g. arguments for calls) in the FrameAccessState.
* Add a flag, --turbo_sp_frame_access, which forces all frame
access to be sp-based whenever possible. This will likely never
be used in production, but for testing it's useful in verifying
that the stack-tracking of each platform maintained in the
FrameAccessState is correct.
* Use sp-based frame access for gap resolving before tail
calls. This will allow for slightly more efficient restoration
of the frame pointer in the tail call in a later CL.
* Remove most ad hoc groping into CallDescriptors to
determine if a frame is needed, instead consistently use
predicates like needs_frame(), IsCFunctionCall() and
IsJSFunctionCall().
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1460183002
Cr-Commit-Position: refs/heads/master@{#32234}
Reason for revert:
Fails on V8 Fuzzer: https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/6028
Original issue's description:
> Move --harmony-destructuring-bind to shipping
>
> Also fix CheckConflictingVarDeclarations() to properly handle
> legacy const bindings. Without that change enabling the flag
> causes code like:
>
> function f() { const x; var x; }
>
> to throw an early error, rather than wait to throw the error
> until f is invoked.
>
> BUG=v8:811
> LOG=y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/515093630a4a925a66d550561e38293d49633f10
> Cr-Commit-Position: refs/heads/master@{#32222}
TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811
Review URL: https://codereview.chromium.org/1470333002
Cr-Commit-Position: refs/heads/master@{#32226}
Also fix CheckConflictingVarDeclarations() to properly handle
legacy const bindings. Without that change enabling the flag
causes code like:
function f() { const x; var x; }
to throw an early error, rather than wait to throw the error
until f is invoked.
BUG=v8:811
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1451843002
Cr-Commit-Position: refs/heads/master@{#32222}
This patch removes Promise functions and methods which are absent
from the ES2015 specification when the --es-staging flag is on.
BUG=v8:3237
R=rossberg
LOG=Y
Review URL: https://codereview.chromium.org/1469543003
Cr-Commit-Position: refs/heads/master@{#32194}
Reason for revert:
Janks finalization of full GC.
Original issue's description:
> [heap] Preserve optimized code maps accross GCs.
>
> This disables the eager flushing of optimized code maps during full GCs
> and instead treats entries in those tables weakly by default. Note that
> for now entries are removed when one of its components dies.
>
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/7a1377aab2ba4e2c9a7d422b51f645cbbaec10c7
> Cr-Commit-Position: refs/heads/master@{#32045}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1467213002
Cr-Commit-Position: refs/heads/master@{#32173}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
This disables the eager flushing of optimized code maps during full GCs
and instead treats entries in those tables weakly by default. Note that
for now entries are removed when one of its components dies.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1430293002
Cr-Commit-Position: refs/heads/master@{#32045}
This CL fixes several sources of non-predictability by making Platform::MonotonicallyIncreasingTime() the only bottleneck for all time-querying functions and providing PredictablePlatform implementation.
Review URL: https://codereview.chromium.org/1415383004
Cr-Commit-Position: refs/heads/master@{#31959}
Adds a blacklist of tests which are currently unsupported or broken in Ignition to
the mjsunit and test262 test status.
Also removes --ignition-script-filter flag, and adds a
--ignition_fallback_on_eval_and_catch flag which fallsback to fullcodegen for
functions which call eval or contain a catch block.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1420963009
Cr-Commit-Position: refs/heads/master@{#31864}
It was originally shipped in https://crrev.com/eef2b9b09723ba1dae3ec0172341e93e9030ada0,
but was reverted due to poor interaction with Blink.
That interaction seems to be fixed thanks to changes to the V8 API
and to @@toStringTag handling on access-checked objects.
BUG=v8:3502
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.v8:v8_linux_nosnap_rel;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1406293011
Cr-Commit-Position: refs/heads/master@{#31846}
Since enabling destructuring already implies enabling default parameters,
there's not a good way to separate these two. Luckily, they're both
feature-complete (save for destructuring assignment).
This causes us to pass an additional 24 test262 tests.
BUG=v8:811, v8:2160
LOG=y
Review URL: https://codereview.chromium.org/1407393009
Cr-Commit-Position: refs/heads/master@{#31844}
This patch moves ES2015 ToLength semantics on array operations, etc
to from staging to shipping.
R=adamk
BUG=v8:3087
LOG=Y
Review URL: https://codereview.chromium.org/1433473003
Cr-Commit-Position: refs/heads/master@{#31810}
Many places in the JavaScript standard library are changed in ES2015 from
getting an integer using ToUint32 to using ToLength. This patch stages
the flag turning on those new semantics.
BUG=v8:3087,v8:4244
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1426673003
Cr-Commit-Position: refs/heads/master@{#31641}
Adds a scavenge GC pass that collects unmodified references instead of
processing object groups. This mode can be controlled by setting
FLAG_scavenge_reclaim_unmodified_objects. By default this is turned off.
Also, modified a test case to suit the handle the new GC pass.
BUG=v8:4421
LOG=N
Review URL: https://codereview.chromium.org/1410593005
Cr-Commit-Position: refs/heads/master@{#31599}
This patch switches sloppy-mode code from legacy const semantics
to ES2015 semantics. It is unknown how much of the web will be
broken by this; likely the patch will have to be reverted before
a branch happens.
BUG=v8:3739
LOG=Y
R=rossberg,adamk
Review URL: https://codereview.chromium.org/1420223003
Cr-Commit-Position: refs/heads/master@{#31525}
Both the JSTypeFeedbackSpecializer and the JSTypeFeedbackLowering is
dead code by now, since the more general JSNativeContextSpecialization
deals with the property/global load/store type feedback in a way that
also interacts properly with inlining.
BUG=v8:4470
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1407913003 .
Cr-Commit-Position: refs/heads/master@{#31462}
This stages the general purpose inlining mechanism in TurboFan and
also disables the remaining tests that still fail. We do this to get
test coverage early and to avoid regressing inlining as we go along.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1419623002
Cr-Commit-Position: refs/heads/master@{#31406}
This stages the general purpose inlining mechanism in TurboFan and also
disables the remaining tests that still fail. We do this to get test
coverage early and to avoid regressing inlining as we go along.
R=bmeurer@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1412703002
Cr-Commit-Position: refs/heads/master@{#31386}
Reason for revert:
This still breaks Inbox.
Original issue's description:
> Stage --harmony_sloppy_function
>
> This patch turns on ES2015-style function hoisting semantics in
> staging. --harmony_sloppy_function was previously staged, leading
> to a number of bugs being filed and the staging being reversed;
> important bugs have been fixed, so it is time to try again.
>
> R=adamk
> LOG=Y
> BUG=v8:4285
>
> Committed: https://crrev.com/333e27fd99f8187c97e62b9538529900f0a30668
> Cr-Commit-Position: refs/heads/master@{#31190}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4285
Review URL: https://codereview.chromium.org/1402763003
Cr-Commit-Position: refs/heads/master@{#31206}
This patch turns on ES2015-style function hoisting semantics in
staging. --harmony_sloppy_function was previously staged, leading
to a number of bugs being filed and the staging being reversed;
important bugs have been fixed, so it is time to try again.
R=adamk
LOG=Y
BUG=v8:4285
Review URL: https://codereview.chromium.org/1393423002
Cr-Commit-Position: refs/heads/master@{#31190}
Add a flag to explicitly filter scripts in ignition and use it for the test262
variant. The previous approach of overloading ignition-filter meant that only
top-level code was getting compiled through ignition.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1396493002
Cr-Commit-Position: refs/heads/master@{#31164}
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context. Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.
Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations. Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
Cr-Commit-Position: refs/heads/master@{#31139}
Review URL: https://codereview.chromium.org/1387393002
Cr-Commit-Position: refs/heads/master@{#31148}
Reason for revert:
Breaks GC stress: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/1984/steps/Bisect%20c5528ac1.Retry/logs/regress-crbug-450960
Original issue's description:
> [turbofan] Add initial support for global specialization.
>
> Introduce a new JSGlobalSpecialization advanced reducer that runs
> during the initial inlining and context specialization, and specializes
> the graph to the globals of the native context. Currently we assume
> that we do not inline cross native context, but long-term we will grab
> the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
> new global load/store ICs that are currently in the workings), and then
> this whole specialization will be fully compositional even across
> cross-context inlining.
>
> Note that we cannot really handle most of the stores to global object
> property cells because TurboFan doesn't have a mechanism to enforce
> certain representations. Also note that we cannot yet fully benefit
> from the type feedback collected on the global object property cells,
> because the type system cannot deal with maps in a reasonable way.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
> Cr-Commit-Position: refs/heads/master@{#31139}
TBR=jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470
Review URL: https://codereview.chromium.org/1390073004
Cr-Commit-Position: refs/heads/master@{#31144}
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context. Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.
Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations. Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1387393002
Cr-Commit-Position: refs/heads/master@{#31139}
Reason for revert:
[Sheriff] Speculative revert due to crbug.com/539814
Original issue's description:
> Changed scavenge GC to collect unmodified references
>
> Added a scavenge GC pass that collects unmodified references instead of
> processing object groups. This mode can be controlled by setting
> FLAG_scavenge_remove_unmodified_objects. By default this is turned off.
> Also, modified a test case to suit the handle the new GC pass.
>
> BUG=v8:4421
> LOG=N
>
> Committed: https://crrev.com/6254019238a853c9f3c09d615ba153043f6957c7
> Cr-Commit-Position: refs/heads/master@{#31102}
TBR=jochen@chromium.org,rmcilroy@chromium.org,mythria@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4421,chromium:539814
Review URL: https://codereview.chromium.org/1388133002
Cr-Commit-Position: refs/heads/master@{#31130}
Added a scavenge GC pass that collects unmodified references instead of
processing object groups. This mode can be controlled by setting
FLAG_scavenge_remove_unmodified_objects. By default this is turned off.
Also, modified a test case to suit the handle the new GC pass.
BUG=v8:4421
LOG=N
Review URL: https://codereview.chromium.org/1358703003
Cr-Commit-Position: refs/heads/master@{#31102}
Arrow functions have been enabled by default since the 4.5 branch.
Review URL: https://codereview.chromium.org/1373633002
Cr-Commit-Position: refs/heads/master@{#31031}
The current implemention breaks sloppy mode code that uses function
declarations inside blocks at top-level. Work is ongoing on a patch
to fix this issue, but in the meantime it seems reasonable to move
the feature out of staging.
Manual revert of commit 6e07f5a75b.
R=littledan@chromium.org
BUG=chromium:535836
LOG=y
Review URL: https://codereview.chromium.org/1375213005
Cr-Commit-Position: refs/heads/master@{#31029}
This name makes it clear that the flag (also the variant in the Compiler)
is talking about specializing to the function context instead of i.e. the
native context.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1372513003
Cr-Commit-Position: refs/heads/master@{#30934}
It's been enabled since M45, which is now well into its stable period,
with no problems reported.
Review URL: https://codereview.chromium.org/1356793002
Cr-Commit-Position: refs/heads/master@{#30835}
Defines a new --harmony-tolength flag, and a ToLengthFlagged() runtime function,
that is used where ES6 requires ToLength(), but a pre-ES6 conversion existed
before. When the flag is disabled, the function uses TO_UINT32(), which is
the pre-ES6 behaviour. When the flag enabled, the ES6-compliant ToLength()
conversion is used.
Based on a patch initially from Diego Pino <dpino@igalia.com>
BUG=v8:3087
LOG=Y
Review URL: https://codereview.chromium.org/1309243003
Cr-Commit-Position: refs/heads/master@{#30772}
There isn't a plan to turn it on soon, so we'll take it out in favor of cleaner code.
BUG=
Review URL: https://codereview.chromium.org/1202173002
Cr-Commit-Position: refs/heads/master@{#30767}
Some pretty hacky code was used to carry out the tail-call
handler dispatch on ia32 vector stores due to a lack
of free registers. It really tanks performance. A better
approach is to use a virtual register on the isolate.
BUG=
Review URL: https://codereview.chromium.org/1336313002
Cr-Commit-Position: refs/heads/master@{#30718}
This removes the aforementioned flag which has been on by default for a
while now. Note that this does not control optimization decisions, only
the last-resort bailout in the graph builder.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1335543002
Cr-Commit-Position: refs/heads/master@{#30673}
Adds support for property store operations via Store/KeyedStore ICs. Adds the
following bytecodes:
- StoreIC
- KeyedStoreIC
The --vector_store flag is now required for --ignition.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1319833004
Cr-Commit-Position: refs/heads/master@{#30660}
- Modify js2c to accept --js and --nojs,
- modify mksnapshot to accept --startup_src
(instead of a positional parameter, so that it can be omitted),
- modify v8.gyp to use the above so that no target has multiple
output dependencies, and
- update GN to use the switches above.
(I have not succeeded in fixing the GYP->make translator to properly map
multi-output rules, so that they work as expected in all edge cases.
This CL signals defeat on that front, and instead I rewrite the GYP
file to avoid that situation in the first place.)
R=jochen@chromium.org
BUG=v8:4382
LOG=N
Review URL: https://codereview.chromium.org/1310273009
Cr-Commit-Position: refs/heads/master@{#30640}
Once a range is found to have a conflict, split around all the calls it
crosses over, since it will anyway have conflicts there, too.
Incrementally, from the last change to greedy, this change brings
overall improvement in benchmarks. In fact, except for 2 regressions
in Jetstream (splay-latency and date-format-xparb, at 6 and 7%
respectivelly), everything else is in the green or noise. Quite a few
benchmarks are over 3%, with a few (zlib, for example) in the double
digits.
Review URL: https://codereview.chromium.org/1328783002
Cr-Commit-Position: refs/heads/master@{#30579}
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which is now a SyntaxError.
BUG=v8:3305
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1321013005
Cr-Commit-Position: refs/heads/master@{#30525}
Reason for revert:
Fails a test262 test with --always-opt.
Original issue's description:
> Stage sloppy let
>
> Move the --harmony-sloppy-let flag to staging for further testing, and
> update test262 for the new passing tests. Also increase the strictness
> of the parser, even in sloppy mode, to disallow "new legacy compat" for
>
> for (let x = 5 in {}) {}
>
> which is now a SyntaxError.
>
> BUG=v8:3305
> LOG=Y
> R=adamk
>
> Committed: https://crrev.com/07bc0117be8dc9e63ec14d5f9645c483d60a1bec
> Cr-Commit-Position: refs/heads/master@{#30515}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3305
Review URL: https://codereview.chromium.org/1324033002
Cr-Commit-Position: refs/heads/master@{#30518}
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which is now a SyntaxError.
BUG=v8:3305
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1327483002
Cr-Commit-Position: refs/heads/master@{#30515}
We completely un-wired the greedy allocator to focus on the
stackchecks in loops (splintering) work. This change re-wires greedy,
still behind its flag. For now, enabling the greedy allocator disables
the stackchecks in loops feature (and range splintering), so that we are
at the baseline we left it at.
The main contribution in this change is adapting the codebase after
the live range model refactoring, whereby RegisterAllocationData's
live_ranges() contains just top-level ranges, and children are accessed
via their parents.
BUG=
Review URL: https://codereview.chromium.org/1320363002
Cr-Commit-Position: refs/heads/master@{#30492}
When encountering a "=" token in ParseAssignmentExpression, the default
parameter case is not locally distinguishable from the destructuring case.
BUG=
Review URL: https://codereview.chromium.org/1317843002
Cr-Commit-Position: refs/heads/master@{#30386}
The lack of marking this dependency led to a ClusterFuzz crash when
sloppy-function was on but not sloppy. This case does not make sense.
R=adamk
LOG=N
BUG=chromium:520891
Review URL: https://codereview.chromium.org/1316773004
Cr-Commit-Position: refs/heads/master@{#30364}
This change encompasses what is necessary to enable stack checks in loops without suffering large regressions.
Primarily, it consists of a new mechanism for dealing with deferred blocks by "splintering", rather than splitting, inside deferred blocks.
My initial change was splitting along deferred block boundaries, but the regression introduced by stackchecks wasn't resolved conclusively. After investigation, it appears that just splitting ranges along cold block boundaries leads to a greater opportunity for moves on the hot path, hence the suboptimal outcome.
The alternative "splinters" ranges rather than splitting them. While splitting creates 2 ranges and links them (parent-child), in contrast, splintering creates a new independent range with no parent-child relation to the original. The original range appears as if it has a liveness hole in the place of the splintered one. All thus obtained ranges are then register allocated with no change to the register allocator.
The splinters (cold blocks) do not conflict with the hot path ranges, by construction. The hot path ones have less pressure to split, because we remove a source of conflicts. After allocation, we merge the splinters back to their original ranges and continue the pipeline. We leverage the previous changes made for deferred blocks (determining where to spill, for example).
Review URL: https://codereview.chromium.org/1305393003
Cr-Commit-Position: refs/heads/master@{#30357}
Embedders would use these for features which must be able to be turned
off at runtime, despite being compiled into V8. They can be turned on
and off by the embedder using the --experimental_extras flag, e.g. via
v8::SetFlagsFromString.
R=yangguo@chromium.org, mlippautz@chromium.org, hpayer@chromium.org
BUG=chromium:507137
LOG=Y
Review URL: https://codereview.chromium.org/1284413002
Cr-Commit-Position: refs/heads/master@{#30260}
Bytecode generator for local assignment and basic binary operations.
Command-line flag for printing bytecodes.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1294543002
Cr-Commit-Position: refs/heads/master@{#30221}
Restricts linux perf-event code range reporting to functions only (i.e. on
stubs.) While this makes the gathered ticks less accurate, it reduces the
growth of the /tmp/perf-${pid}.map file.
BUG=v8:3453
R=hablich@chromium.org,danno@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1292743002
Cr-Commit-Position: refs/heads/master@{#30179}
This patch puts --harmony-sloppy into staging. Now that let, lexically-scoped
functions and ES2015 sloppy mode const semantics have been split off into
separate flags, the change only enables classes in sloppy mode.
BUG=v8:3305
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1288153003
Cr-Commit-Position: refs/heads/master@{#30141}
In an initial attempt to implement sloppy mode lexical bindings,
functions were made lexically scoped in sloppy mode. However, the
ES2015 spec says that they need an additional hoisted var binding,
and further, it's not clear when we'll implement that behavior
or whether it's web-compatible.
This patch splits off function block scoping into a new, separate
flag called --harmony_sloppy_function. This change will enable the
possibility of testing and shipping this feature separately from
other block scoping-related features which don't have the same risks.
BUG=v8:4285
R=adamk
LOG=N
Review URL: https://codereview.chromium.org/1282093002
Cr-Commit-Position: refs/heads/master@{#30122}
With the recent changes to the incremental marking API we can now kick off
incremental marking while respecting callback flags.
Performance neutral for smoothness.image_decoding_cases on N9 (read: does not
crash) as long as we synchronously process phantom callbacks
(kGCCallbackFlagForced).
OORT single run:
"marksweep": {
"count": 5,
"pause_min": 7.5,
"pause_max": 158.8,
"pause_avg": 97.52000000000001,
"pause_gt_10ms": 4
}
--- vs ---
"marksweep": {
"count": 5,
"pause_min": 16.2,
"pause_max": 22.1,
"pause_avg": 19.32,
"pause_gt_10ms": 5
}
The number of actual full GCs varies. The improvement manifests in reduced
maximum and average pauses.
BUG=chromium:515795
LOG=N
Review URL: https://codereview.chromium.org/1271253002
Cr-Commit-Position: refs/heads/master@{#30028}
To avoid tanking context startup performance, only the actual installation of the
JS-exposed API is flag-guarded. The remainder of the implementation still
resides in the snapshot.
Review URL: https://codereview.chromium.org/1257063003
Cr-Commit-Position: refs/heads/master@{#30017}
Added a separate flag for this, since we intend to enable it for the linear allocator as well. Currently, the option is "on" for greedy, as a point in time to enable its testing (through the greedy allocator bots).
BUG=
Review URL: https://codereview.chromium.org/1256313003
Cr-Commit-Position: refs/heads/master@{#30005}
Reason for revert:
Suspected to cause Canary crashes
Original issue's description:
> Reland^2 "Enable loads and stores to global vars through property cell shortcuts installed into parent script context".
>
> This reverts commit 362b378501.
>
> R=ishell@chromium.org
>
> Committed: https://crrev.com/440ae014e56924b52337c3747221b79283f07b81
> Cr-Commit-Position: refs/heads/master@{#29849}
TBR=ishell@chromium.org,v8-mips-ports@googlegroups.com,plind44@gmail.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/1260423002
Cr-Commit-Position: refs/heads/master@{#29905}
Reason for revert:
This CL may be the reason for the spike on memory corruption. Tentatively reverting this CL.
BUG=chromium:512780
LOG=n
Original issue's description:
> Activate preserving of optimized code map accross GCs.
>
> This enables --noflush-optimized-code-cache which allows preserving
> entries in the optimized code map accross GCs. This only applies to
> values being reachable through other paths.
>
> R=hpayer@chromium.org,hablich@chromium.org
>
> Committed: https://crrev.com/1a8776db25b63c4ce718423772d1fd13f58eeab5
> Cr-Commit-Position: refs/heads/master@{#29755}
TBR=hablich@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1255043003
Cr-Commit-Position: refs/heads/master@{#29888}
--harmony_sloppy includes behavior to turn on sloppy mode lexical
bindings. Before this patch, it also included a way to parse let
which is likely web-incompatible (let is disallowed as an
identifier). This patch splits off the let parsing from the more
general block scoping code, so that block scoping can be developed
independently.
R=adamk
LOG=N
BUG=v8:3305
Review URL: https://codereview.chromium.org/1255013002
Cr-Commit-Position: refs/heads/master@{#29855}
This function will be used later instead of HasLowAllocationRate
to decide how many pages to compact.
BUG=chromium:502247
LOG=NO
Review URL: https://codereview.chromium.org/1254603002
Cr-Commit-Position: refs/heads/master@{#29841}
Adds basic support for generation of interpreter bytecode handler code
snippets. The InterpreterAssembler class exposes a set of low level,
interpreter specific operations which can be used to build a Turbofan
graph. The Interpreter class generates a bytecode handler snippet for
each bytecode by assembling operations using an InterpreterAssembler.
Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1239793002
Cr-Commit-Position: refs/heads/master@{#29814}
This preserves the context-independent entry in an optimized code map
across GCs when the code is considered young (i.e. less than 3 ages).
Note that any context-dependent entry for the same code will still be
flushed immediately when the respective context dies, hence context
lifetime is not increased.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1252463002
Cr-Commit-Position: refs/heads/master@{#29790}
This enables --noflush-optimized-code-cache which allows preserving
entries in the optimized code map accross GCs. This only applies to
values being reachable through other paths.
R=hpayer@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1217863006
Cr-Commit-Position: refs/heads/master@{#29755}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29689}
Return both --harmony-spreadcalls and --harmony-spread-arrays
to staging, in preparation for disabling those features on
the M45 branch.
There are no known bugs in spread calls, but without rest and spread
arrays it seems appropriate to leave all of them out rather than
only supporting a singular use of the '...' operator.
BUG=v8:4298
LOG=y
Review URL: https://codereview.chromium.org/1230773005
Cr-Commit-Position: refs/heads/master@{#29657}
Reason for revert:
[Sheriff] This changes lots of layout tests. See comment on CL.
Original issue's description:
> Enable loads and stores to global vars through property cell shortcuts installed into parent script context.
>
> Committed: https://crrev.com/cd61b047f1ab92c353a629556f9d3ad571ace1b1
> Cr-Commit-Position: refs/heads/master@{#29595}
TBR=verwaest@chromium.org,ishell@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1236863002
Cr-Commit-Position: refs/heads/master@{#29599}
This CL also adds hydrogen stubs for global loads and global stores, full-codegen and TurboFan now uses this machinery.
Review URL: https://codereview.chromium.org/1224793002
Cr-Commit-Position: refs/heads/master@{#29592}
The breakage to Chrome seems to be based on @@isConcatSpreadable
and turning that part off with this patch fixes the Maps Tips & Tricks
test case.
BUG=chromium:507553
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1226063002
Cr-Commit-Position: refs/heads/master@{#29545}
Conditionally including Array and TypedArray methods seems to cause
a slowdown in V8 context creation, possibly due to the new code added.
BUG=chromium:504629
R=adamk@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1215863003
Cr-Commit-Position: refs/heads/master@{#29430}
This allows context-independent code generated by TurboFan to be cached
in the optimized code map and reused across native contexts. Note that
currently this cache is still flushed at GC time.
R=bmeurer@chromium.org,mvstanton@chromium.org
TEST=cctest/test-compiler/OptimizedCodeSharing
Review URL: https://codereview.chromium.org/1208013002
Cr-Commit-Position: refs/heads/master@{#29313}
Turning the --harmony-array flag on has been delayed behind
unrelated test failures. Now that those tests are disabled,
land the changes.
This patch fixes WebKit tests based on the new change.
R=adamk
LOG=Y
BUG=v8:3578
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1199113003
Cr-Commit-Position: refs/heads/master@{#29209}
Reasons:
- It is not used.
- It complicates code in GC.
BUG=chromium:499713
LOG=NO
Review URL: https://codereview.chromium.org/1184723002
Cr-Commit-Position: refs/heads/master@{#29027}
This allows try-catch and try-finally constructs to be separately
enabled and disabled. We plan to stage try-catch support soon.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1157863015
Cr-Commit-Position: refs/heads/master@{#28848}
Embed constant pools within their corresponding Code
objects.
This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.
Currently supported on PPC and ARM. Enabled by default on
PPC only.
This yields a 6% improvment in Octane on PPC64.
R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y
Review URL: https://codereview.chromium.org/1162993006
Cr-Commit-Position: refs/heads/master@{#28801}
Stage 1 implementation:
- Parameters can't be referenced before initialized (from left-to-right)
- SingleNameBindings only, no support for BindingPatterns
Known issues:
- Incorrect scoping (parameter expressions may reference variables declared in function body)
- Function arity is untouched
- Hole-checking needs work
- Rest parameters are broken when mixed with optional arguments
BUG=v8:2160
LOG=N
R=arv@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1127063003
Cr-Commit-Position: refs/heads/master@{#28739}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28594}
Reason for revert:
breaks build
Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}
TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1149203003
Cr-Commit-Position: refs/heads/master@{#28589}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28588}
This follows the logic of the load ics, in that the base extra ic state is
better encapsulated.
Introduce flag vector_stores to aid development of vector-based store ics.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1151253004
Cr-Commit-Position: refs/heads/master@{#28576}
This allows enabling TurboFan on a certain subset of language features
in the AstNumberingVisitor. The heuristics of when to optimize remain
unchanged, only the choice of which optimizing compiler to use changes.
R=bmeurer@chromium.org
BUG=v8:4131
LOG=N
Review URL: https://codereview.chromium.org/1155503002
Cr-Commit-Position: refs/heads/master@{#28544}
Replace the --turbo-deoptimization flag with --turbo-asm-deoptimization
and enable deoptimization for non-asm.js TurboFan code unconditionally.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1153483002
Cr-Commit-Position: refs/heads/master@{#28543}
This allows you to put iterables into your array literals
and the will get spread into the array.
let x = [0, ...range(1, 3)]; // [0, 1, 2]
This is done by treating the array literal up to the first
spread element as usual, including using a boiler plate
array, and then appending the remaining expressions and rest
expressions.
BUG=v8:3018
LOG=N
Review URL: https://codereview.chromium.org/1125183008
Cr-Commit-Position: refs/heads/master@{#28534}
This introduces V8.MemoryHeapCommitted and V8.MemoryHeapUsed histograms.
In contrast to the existing memory histograms, the new histograms are uniform in time, i.e. their samples happen at regular time intervals. The --histogram-interval specifies the length of the interval.
We implement this by linearly interpolating memory stats between GC and idle notification events.
BUG=chromium:485472
LOG=NO
Review URL: https://codereview.chromium.org/1125683004
Cr-Commit-Position: refs/heads/master@{#28292}
Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).
Also explicitly limit tail call optimization to stubs for now and drop
the global flag.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1114163005
Cr-Commit-Position: refs/heads/master@{#28219}
This introduces a simplified allocation operator which can be used to
model inline allocations in TurboFan. It is currently used for context
allocations, but still disabled because change lowering introduces
floating allocations outside the effect chain that interfere.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1109773002
Cr-Commit-Position: refs/heads/master@{#28195}
This CL contains the first steps towards tail call optimization:
* Structurally detect tail calls during instruction selection,
looking for special return/call combinations.
* Added new architecture-specific instructions for tail calls which
jump instead of call and take care of frame adjustment.
* Moved some code around.
Currently we restrict tail calls to callees which only use registers
for arguments/return value and to call sites which are explicitly
marked as being OK for tail calls. This excludes, among other things,
call sites in sloppy JS functions and our IC machinery (both need in
general to be able to access the caller's frame).
All this is behind a flag --turbo-tail-calls, which is currently off
by default, so it can easily be toggled.
Review URL: https://codereview.chromium.org/1108563002
Cr-Commit-Position: refs/heads/master@{#28150}
This change aims to introduce the separation of the RegisterAllocator model, using the initial prototype for GreedyAllocator as proof of concept.
Summary:
- new flag, turbo-greedy-regalloc, enabling the new allocator. Default
false.
- initial, untested implementation for the GreedyAllocator.
BUG=
Review URL: https://codereview.chromium.org/1061923005
Cr-Commit-Position: refs/heads/master@{#28018}
Reason for revert:
Breaks Static Initializers test.
http://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/3210/steps/Static-Initializers/logs/stdio
Original issue's description:
> Introducing the LLVM greedy register allocator.
>
> This change aims to introduce the separation of the RegisterAllocator model,
> using the initial prototype for RegisterAllocatorGreedy as proof of concept.
>
> Summary:
> - new flag, turbo-greedy-regalloc, enabling the new allocator. Default
> false.
> - separated RegisterAllocator into a base type and two derived,
> RegisterAllocatorLinear (the one currently used in TurboFan) and
> RegisterAllocatorGreedy (the new one).
> - initial, untested impementation for the greedy allocator.
>
> BUG=
>
> Committed: https://crrev.com/ec542dea6b6a0cb82d1578a389569d019a59121d
> Cr-Commit-Position: refs/heads/master@{#28015}
TBR=dcarney@chromium.org,titzer@chromium.org,jarin@chromium.org,jvoung@chromium.org,mtrofin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1080953006
Cr-Commit-Position: refs/heads/master@{#28017}
This change aims to introduce the separation of the RegisterAllocator model,
using the initial prototype for RegisterAllocatorGreedy as proof of concept.
Summary:
- new flag, turbo-greedy-regalloc, enabling the new allocator. Default
false.
- separated RegisterAllocator into a base type and two derived,
RegisterAllocatorLinear (the one currently used in TurboFan) and
RegisterAllocatorGreedy (the new one).
- initial, untested impementation for the greedy allocator.
BUG=
Review URL: https://codereview.chromium.org/1061923005
Cr-Commit-Position: refs/heads/master@{#28015}
This flag is intended as a staging flag for TurboFan. It serves as a
single flag that always enables a most recent configuration of TurboFan
for test suites and benchmarks, without needing to update test drivers.
R=titzer@chromium.org,machenbach@chromium.org
Review URL: https://codereview.chromium.org/1094573002
Cr-Commit-Position: refs/heads/master@{#27896}
Split interface and implementation of ControlEquivalence and add a
dedicated trace flag --trace-turbo-ceq to make it reusable outside the
scheduler.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1056093005
Cr-Commit-Position: refs/heads/master@{#27862}
The cells are stored on prototypes (in their map's PrototypeInfo). When a prototype object changes its map, then both its own validity cell and those of all "downstream" prototypes are invalidated; handlers for a given receiver embed the currently valid cell for that receiver's prototype during their compilation and check it on execution.
Review URL: https://codereview.chromium.org/908213002
Cr-Commit-Position: refs/heads/master@{#27845}
- ConstantOperand was using a too-small field too store its virtual register
- drop ConvertTo, replace it with simple copy
- split AllocatedOperand off from Immediate and Constant to make assignment clearer, also paving the way for small Immediates
- put zone first in *Operand::New
- driveby: drop delayed ssa deconstruction experiment
R=titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1050803002
Cr-Commit-Position: refs/heads/master@{#27692}
Reason for revert:
this indeed drops the max major gc time considerable, so turn it back on
Original issue's description:
> Turn off overapproximation of the weak closure again
>
> As long as we still have to process global handles, the impact is not
> yet worthwhile
>
> BUG=v8:3862
> R=hpayer@chromium.org
> LOG=y
>
> Committed: https://crrev.com/294cdc6aecbd7f76be68217da4b3d35901ebce4b
> Cr-Commit-Position: refs/heads/master@{#27570}
TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3862
Review URL: https://codereview.chromium.org/1068723003
Cr-Commit-Position: refs/heads/master@{#27616}
Reason for revert:
Reverting risky GC changes that block v8 roll.
Original issue's description:
> Reland "Filter invalid slots out from the SlotsBuffer after marking."
>
> > There are two reasons that could cause invalid slots appearance in SlotsBuffer:
> > 1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
> > 2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
>
> > This CL also adds useful machinery that helps triggering incremental write barriers.
>
> > BUG=chromium:454297
> > LOG=Y
>
> NOTRY=true
>
> Committed: https://crrev.com/f86aadd1d45c756467dff8e08a055b462d7a060b
> Cr-Commit-Position: refs/heads/master@{#27433}
TBR=machenbach@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1041593002
Cr-Commit-Position: refs/heads/master@{#27491}
> There are two reasons that could cause invalid slots appearance in SlotsBuffer:
> 1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
> 2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
> This CL also adds useful machinery that helps triggering incremental write barriers.
> BUG=chromium:454297
> LOG=Y
NOTRY=true
Review URL: https://codereview.chromium.org/1032833002
Cr-Commit-Position: refs/heads/master@{#27433}
Reason for revert:
Need to revert in order to revert https://codereview.chromium.org/1029323003/
Original issue's description:
> Filter invalid slots out from the SlotsBuffer after marking.
>
> There are two reasons that could cause invalid slots appearance in SlotsBuffer:
> 1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
> 2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
>
> This CL also adds useful machinery that helps triggering incremental write barriers.
>
> BUG=chromium:454297
> LOG=Y
>
> Committed: https://crrev.com/5c47c1c0d3e4a488f190c16a64ee02f5a14e6561
> Cr-Commit-Position: refs/heads/master@{#27423}
TBR=hpayer@chromium.org,erik.corry@gmail.com,ishell@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:454297
Review URL: https://codereview.chromium.org/1033453005
Cr-Commit-Position: refs/heads/master@{#27426}
There are two reasons that could cause invalid slots appearance in SlotsBuffer:
1) If GC trims "tail" of an array for which it has already recorded a slots and then migrate another object to the "tail".
2) Tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
This CL also adds useful machinery that helps triggering incremental write barriers.
BUG=chromium:454297
LOG=Y
Review URL: https://codereview.chromium.org/1010363005
Cr-Commit-Position: refs/heads/master@{#27423}
This change introduces a liveness analyzer for local variables in frame states.
The main idea is to use the AstGraphBuilder::Environment class to build the control flow graph, and record local variable loads, stores and checkpoints in the CFG basic blocks (LivenessAnalyzerBlock class).
After the graph building finishes, we run a simple data flow analysis over the CFG to figure out liveness of each local variable at each checkpoint. Finally, we run a pass over all the checkpoints and replace dead local variables in the frame states with the 'undefined' value.
Performance numbers for Embenchen are below.
----------- box2d.js
Current --turbo-deoptimization: EmbenchenBox2d(RunTime): 11265 ms.
d8-master --turbo-deoptimization: EmbenchenBox2d(RunTime): 11768 ms.
d8-master: EmbenchenBox2d(RunTime): 10996 ms.
----------- bullet.js
Current --turbo-deoptimization: EmbenchenBullet(RunTime): 17049 ms.
d8-master --turbo-deoptimization: EmbenchenBullet(RunTime): 17384 ms.
d8-master: EmbenchenBullet(RunTime): 16153 ms.
----------- copy.js
Current --turbo-deoptimization: EmbenchenCopy(RunTime): 4877 ms.
d8-master --turbo-deoptimization: EmbenchenCopy(RunTime): 4938 ms.
d8-master: EmbenchenCopy(RunTime): 4940 ms.
----------- corrections.js
Current --turbo-deoptimization: EmbenchenCorrections(RunTime): 7068 ms.
d8-master --turbo-deoptimization: EmbenchenCorrections(RunTime): 6718 ms.
d8-master: EmbenchenCorrections(RunTime): 6858 ms.
----------- fannkuch.js
Current --turbo-deoptimization: EmbenchenFannkuch(RunTime): 4167 ms.
d8-master --turbo-deoptimization: EmbenchenFannkuch(RunTime): 4608 ms.
d8-master: EmbenchenFannkuch(RunTime): 4149 ms.
----------- fasta.js
Current --turbo-deoptimization: EmbenchenFasta(RunTime): 9981 ms.
d8-master --turbo-deoptimization: EmbenchenFasta(RunTime): 9848 ms.
d8-master: EmbenchenFasta(RunTime): 9640 ms.
----------- lua_binarytrees.js
Current --turbo-deoptimization: EmbenchenLuaBinaryTrees(RunTime): 11571 ms.
d8-master --turbo-deoptimization: EmbenchenLuaBinaryTrees(RunTime): 13089 ms.
d8-master: EmbenchenLuaBinaryTrees(RunTime): 10957 ms.
----------- memops.js
Current --turbo-deoptimization: EmbenchenMemOps(RunTime): 7766 ms.
d8-master --turbo-deoptimization: EmbenchenMemOps(RunTime): 7346 ms.
d8-master: EmbenchenMemOps(RunTime): 7738 ms.
----------- primes.js
Current --turbo-deoptimization: EmbenchenPrimes(RunTime): 7459 ms.
d8-master --turbo-deoptimization: EmbenchenPrimes(RunTime): 7453 ms.
d8-master: EmbenchenPrimes(RunTime): 7451 ms.
----------- skinning.js
Current --turbo-deoptimization: EmbenchenSkinning(RunTime): 15564 ms.
d8-master --turbo-deoptimization: EmbenchenSkinning(RunTime): 15611 ms.
d8-master: EmbenchenSkinning(RunTime): 15583 ms.
----------- zlib.js
Current --turbo-deoptimization: EmbenchenZLib(RunTime): 10825 ms.
d8-master --turbo-deoptimization: EmbenchenZLib(RunTime): 11180 ms.
d8-master: EmbenchenZLib(RunTime): 10823 ms.
BUG=
Review URL: https://codereview.chromium.org/949743002
Cr-Commit-Position: refs/heads/master@{#27232}
Reason for revert:
Increased rate of Chrome crashes. Requires further investigation.
Original issue's description:
> Reland of Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer.
>
> The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
> This CL also adds useful machinery that helps triggering incremental write barriers.
>
> BUG=chromium:454297, chromium:465273
> LOG=Y
>
> Committed: https://crrev.com/6d0677d845c47ab9fa297de61d0e3d8e5480a02a
> Cr-Commit-Position: refs/heads/master@{#27141}
TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:454297, chromium:465273
Review URL: https://codereview.chromium.org/1004623003
Cr-Commit-Position: refs/heads/master@{#27207}
The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
This CL also adds useful machinery that helps triggering incremental write barriers.
BUG=chromium:454297, chromium:465273
LOG=Y
Review URL: https://codereview.chromium.org/988363002
Cr-Commit-Position: refs/heads/master@{#27141}
The JSInliner used to load the context from the JSFunction node at
runtime, which introduced a HeapConstant (because we had to materialize
the JSFunction after context specialization) and a LoadField operation,
independent whether the inlinee actually uses the context. This is
rather cumbersome currently, and therefore this is now changed to just
embed the context constant instead. Once we do inlining based on
SharedFunctionInfo rather than JSFunction, we should reconsider this
decision and come up with a proper heuristic.
BUG=v8:3952
LOG=n
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/994523002
Cr-Commit-Position: refs/heads/master@{#27069}
Reason for revert:
It caused a lot of Canary crashes.
Original issue's description:
> Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer.
>
> The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
> This CL also adds useful machinery that helps triggering incremental write barriers.
>
> BUG=chromium:454297
> LOG=Y
>
> Committed: https://crrev.com/9633ebabd405c264d33f603f8798c31f59418dcd
> Cr-Commit-Position: refs/heads/master@{#27054}
TBR=verwaest@chromium.org,hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:454297
Review URL: https://codereview.chromium.org/991793002
Cr-Commit-Position: refs/heads/master@{#27063}
We mark certain builtins for inlining, and those should always be
inlined into optimized code (CrankShaft already handles it this way), so
we should support that in TurboFan as well. Currently this mainly
affects a certain set of Math functions, but once have the basics in
place we can extend this to any kind of builtin/code stub/accessor.
This adds a new flag --turbo_builtin_inlining (enabled by default), that
forces the inliner to always inline builtins marked for inlining, but
does not affect inlining of other functions (this is still controlled by
the --turbo-inlining flag).
BUG=v8:3952
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/993473002
Cr-Commit-Position: refs/heads/master@{#27059}
The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field).
This CL also adds useful machinery that helps triggering incremental write barriers.
BUG=chromium:454297
LOG=Y
Review URL: https://codereview.chromium.org/957273002
Cr-Commit-Position: refs/heads/master@{#27054}
This keeps dying maps alive for FLAG_retain_maps_for_n_gc garbage collections
to increase chances of them being reused for new objects in future and
decrease number of deoptimizations.
BUG=v8:3664
LOG=N
TEST=cctest/test-heap/MapRetaining
Review URL: https://codereview.chromium.org/980523004
Cr-Commit-Position: refs/heads/master@{#27040}
For flushing the input queue, use the input queue lock. Introduce an
explicit refcount to make sure we don't delete the thread object before
all jobs are finished.
BUG=v8:3608
R=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/948863002
Cr-Commit-Position: refs/heads/master@{#26812}
This implements a special case of block cloning to recognize constructs like
if (a ? b : c) { ... }
that happen to be generated by Emscripten quite often.
Review URL: https://codereview.chromium.org/947963002
Cr-Commit-Position: refs/heads/master@{#26808}
ModuleDescriptor will end up holding the set of data described in the
spec as a "Module record". This introduces a little bit of confusion
with ModuleInfo, but I hope that'll become clearer over time.
Also removed the interface-printing flags. We probably want
Module-printing flags, but that can wait until we have more
Module-related structures.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/935723004
Cr-Commit-Position: refs/heads/master@{#26728}
This adds a new ControlFlowOptimizer that - for now - recognizes chains
of Branches generated by the SwitchBuilder for a subset of javascript
switches into Switch nodes. Those Switch nodes are then lowered to
either table or lookup switches.
Also rename Case to IfValue (and introduce IfDefault) for consistency.
BUG=v8:3872
LOG=n
Review URL: https://codereview.chromium.org/931623002
Cr-Commit-Position: refs/heads/master@{#26691}
This CL fixes tests that no longer valid and also fixes two issues:
1. 'super()' in non derived constructors.
2. Failure to step into derived constructors.
R=arv@chromium.org, yurys@chromium.org
BUG=v8:3834
LOG=Y
Review URL: https://codereview.chromium.org/923443003
Cr-Commit-Position: refs/heads/master@{#26628}
This way we can ship \u{..} escapes in strings / identifiers before shipping /u
regexps.
BUG=
Review URL: https://codereview.chromium.org/903703002
Cr-Commit-Position: refs/heads/master@{#26461}
It doesn't do anything for now, but it implies strict mode. Added tests to
test-parsing.cc to test that.
BUG=
Review URL: https://codereview.chromium.org/898983002
Cr-Commit-Position: refs/heads/master@{#26460}
When embedder detaches the global objects, its context must be garbage
collected eventually.
BUG=
Review URL: https://codereview.chromium.org/898663005
Cr-Commit-Position: refs/heads/master@{#26450}
