Skip to content

V
V8
Switch branch/tag
  1. 23 Feb, 2016 2 commits
  3. 22 Feb, 2016 1 commit
  5. 19 Feb, 2016 4 commits
    • rmcilroy's avatar
      [Interpreter] Enable runtime profiler support for Ignition. · b62bf1e6
      rmcilroy authored 
      Adds a profiling counter to each BytecodeArray object, and adds
code to Jump and Return bytecode handlers to update this
counter by the size of the jump or the distance from the return
to the start of the function. This is more accurate than fullcodegen's
approach since it takes forward jumps into account as well as back-edges.

Modifies RuntimeProfiler to track ticks for interpreted frames.
Currently we use the SharedFunctionInfo::profiler_ticks() instead
of adding another to tick field to avoid adding another field to
BytecodeArray since SharedFunctionInfo::profiler_ticks() is only
used by Crankshaft otherwise so we shouldn't need both for

BUG=v8:4689
LOG=N

Review URL: https://codereview.chromium.org/1707693003

Cr-Commit-Position: refs/heads/master@{#34166}
      b62bf1e6
    • nikolaos's avatar
      This patch implements an alternative approach to the rewriting · ed665880
      nikolaos authored 
      of non-pattern expressions, according to the (internally circulated)
design document.  Details to be provided here.

1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
    It is a wrapper for AST nodes that wait for some potential rewriting
    (that may or may not happen).  Also, Is... and As... macros now see
    through RewritableExpressions.

2.  The function state keeps a list of rewritable expressions that must be
    rewritten only if they are used as non-pattern expressions.

3.  Expression classifiers are now templates, parameterized by parser
    traits.  They keep some additional state: a pointer to the list of
    non-pattern rewritable expressions.  It is important that expression
    classifiers be used strictly in a stack fashion, from now on.

4.  The RewriteNonPattern function has been simplified.

BUG=chromium:579913
LOG=N

Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
Cr-Commit-Position: refs/heads/master@{#34154}

Review URL: https://codereview.chromium.org/1702063002

Cr-Commit-Position: refs/heads/master@{#34162}
      ed665880
    • machenbach's avatar
      Revert of Non-pattern rewriting revisited (patchset #3 id:40001 of... · 5bb6b47b
      machenbach authored 
      Revert of Non-pattern rewriting revisited (patchset #3 id:40001 of https://codereview.chromium.org/1702063002/ )

Reason for revert:
[Sheriff] This makes jsfunfuzz unhappy:
https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/7681

Original issue's description:
> This patch implements an alternative approach to the rewriting
> of non-pattern expressions, according to the (internally circulated)
> design document.  Details to be provided here.
>
> 1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
>     It is a wrapper for AST nodes that wait for some potential rewriting
>     (that may or may not happen).  Also, Is... and As... macros now see
>     through RewritableExpressions.
>
> 2.  The function state keeps a list of rewritable expressions that must be
>     rewritten only if they are used as non-pattern expressions.
>
> 3.  Expression classifiers are now templates, parameterized by parser
>     traits.  They keep some additional state: a pointer to the list of
>     non-pattern rewritable expressions.  It is important that expression
>     classifiers be used strictly in a stack fashion, from now on.
>
> 4.  The RewriteNonPattern function has been simplified.
>
> BUG=chromium:579913
> LOG=N
>
> Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
> Cr-Commit-Position: refs/heads/master@{#34154}

TBR=rossberg@chromium.org,bmeurer@chromium.org,titzer@chromium.org,nikolaos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579913

Review URL: https://codereview.chromium.org/1712203002

Cr-Commit-Position: refs/heads/master@{#34158}
      5bb6b47b
    • nikolaos's avatar
      This patch implements an alternative approach to the rewriting · 7f5c864a
      nikolaos authored 
      of non-pattern expressions, according to the (internally circulated)
design document.  Details to be provided here.

1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
    It is a wrapper for AST nodes that wait for some potential rewriting
    (that may or may not happen).  Also, Is... and As... macros now see
    through RewritableExpressions.

2.  The function state keeps a list of rewritable expressions that must be
    rewritten only if they are used as non-pattern expressions.

3.  Expression classifiers are now templates, parameterized by parser
    traits.  They keep some additional state: a pointer to the list of
    non-pattern rewritable expressions.  It is important that expression
    classifiers be used strictly in a stack fashion, from now on.

4.  The RewriteNonPattern function has been simplified.

BUG=chromium:579913
LOG=N

Review URL: https://codereview.chromium.org/1702063002

Cr-Commit-Position: refs/heads/master@{#34154}
      7f5c864a
  7. 17 Feb, 2016 2 commits
  9. 16 Feb, 2016 2 commits
  11. 15 Feb, 2016 1 commit
  13. 12 Feb, 2016 4 commits
    • oth's avatar
      [interpreter] Add bytecodes for JumpIfNotHole with constant · 47c08f5f
      oth authored 
      Adds JumpIfNotHoleConstant and JumpIfNotHoleConstantWide bytecodes
and removes JumpIfHole bytecode.

In situations with large numbers of constants, the generator would
fail because an 8-bit constant could not be reserved for
JumpIfHole/JumpIfNotHole and so a 16-bit constant would be reserved.
Then when patching the bytecode the patcher would discover there was
no wide constant variant of the emitted jump.

BUG=v8:4280,v8:4680
LOG=N

Review URL: https://codereview.chromium.org/1697473002

Cr-Commit-Position: refs/heads/master@{#33952}
      47c08f5f
    • mstarzinger's avatar
      Reland of [interpreter] Correctly thread through catch prediction. (patchset... · 5bbcdfe6
      mstarzinger authored 
      Reland of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1695613002/ )

Reason for revert:
No fix needed, original CL was perfectly fine!

Original issue's description:
> Revert of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1690973002/ )
>
> Reason for revert:
> Depends on the reverted https://codereview.chromium.org/1691723002
>
> Original issue's description:
> > [interpreter] Correctly thread through catch prediction.
> >
> > This change correctly sets the {CatchPrediction} field in exception
> > handler tables for bytecode and optimized code. It also adds tests
> > independent of promise handling for this prediction, to ensure all our
> > backends are in sync on their prediction.
> >
> > R=rmcilroy@chromium.org,yangguo@chromium.org
> > TEST=mjsunit/compiler/debug-catch-prediction
> > BUG=v8:4674
> > LOG=n
> >
> > Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> > Cr-Commit-Position: refs/heads/master@{#33906}
>
> TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4674
>
> Committed: https://crrev.com/c5229b311968fd638a6cd537c341b1055eb7be97
> Cr-Commit-Position: refs/heads/master@{#33922}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674

Review URL: https://codereview.chromium.org/1689113004

Cr-Commit-Position: refs/heads/master@{#33933}
      5bbcdfe6
    • bmeurer's avatar
      [runtime] Introduce FastNewStrictArgumentsStub to optimize strict arguments. · 09d84535
      bmeurer authored 
      The FastNewStrictArgumentsStub is very similar to the recently added
FastNewRestParameterStub, it's actually almost a copy of it, except that
it doesn't have the fast case we have for the empty rest parameter. This
patch improves strict arguments in TurboFan and fullcodegen by up to 10x
compared to the previous version.

Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
for the in-object properties instead of having them as constants in the
Heap class.

Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
interpreter to avoid the runtime call overhead for strict arguments
and rest parameter creation.

R=jarin@chromium.org
TBR=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1693513002

Cr-Commit-Position: refs/heads/master@{#33925}
      09d84535
    • adamk's avatar
      Revert of [interpreter] Correctly thread through catch prediction. (patchset... · c5229b31
      adamk authored 
      Revert of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1690973002/ )

Reason for revert:
Depends on the reverted https://codereview.chromium.org/1691723002

Original issue's description:
> [interpreter] Correctly thread through catch prediction.
>
> This change correctly sets the {CatchPrediction} field in exception
> handler tables for bytecode and optimized code. It also adds tests
> independent of promise handling for this prediction, to ensure all our
> backends are in sync on their prediction.
>
> R=rmcilroy@chromium.org,yangguo@chromium.org
> TEST=mjsunit/compiler/debug-catch-prediction
> BUG=v8:4674
> LOG=n
>
> Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> Cr-Commit-Position: refs/heads/master@{#33906}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674

Review URL: https://codereview.chromium.org/1695613002

Cr-Commit-Position: refs/heads/master@{#33922}
      c5229b31
  15. 11 Feb, 2016 8 commits
  17. 10 Feb, 2016 3 commits
    • ssanfilippo's avatar
      [Interpreter] Handle negative ints in generate-bytecode-expectations. · 8bfd4a5a
      ssanfilippo authored 
      The previous implementation used GetRawOperand(), which allows a nicely
unified handling of all scalar types, but returns an unsigned type.
Because of this, generate-bytecode-expectations couldn't properly handle
negative numbers.

This commit differentiate between different types of scalar operands and
uses the appropriate getter from i::interpreter::BytecodeArrayIterator,
thus correctly handling signed types where needed.

Two new helpers have been added to i::interpreter::Bytecodes:

 * IsImmediateOperandType()
 * IsIndexOperandType()

with the intuitive semantic.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1684113002

Cr-Commit-Position: refs/heads/master@{#33874}
      8bfd4a5a
    • rmcilroy's avatar
      [Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. · d1c28849
      rmcilroy authored 
      Moves InterpreterAssembler out of the compiler directory and into the
interpreter directory. Makes InterpreterAssembler as subclass of
CodeStubAssembler.

As part of this change, the special bytecode dispatch linkage type
is removed and instead we use a InterfaceDispatchDescriptor and
a normal CodeStub linkage type.

Removes a bunch of duplicated logic in InterpreterAssembler and
instead uses the CodeStubAssembler logic. Refactors Interpreter
with these changes.

Modifies CodeStubAssembler to add the extra operations required
by the Interpreter (extra call types, raw memory access and some extra
binary ops). Also adds the ability for subclasses to add extra
prologue and epilogue operations around calls, which is required
for the Interpreter.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1673333004

Cr-Commit-Position: refs/heads/master@{#33873}
      d1c28849
    • yangguo's avatar
      [debugger] introduce abstract interface for break location. · 24b40f35
      yangguo authored 
      The break location heavily relies on relocation info. This change
abstracts that away. Currently there is only one implementation for
this interface, for JIT code. Future changes will introduce an
implementation to iterate bytecode arrays.

R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

Review URL: https://codereview.chromium.org/1682853003

Cr-Commit-Position: refs/heads/master@{#33869}
      24b40f35
  19. 08 Feb, 2016 3 commits
    • mstarzinger's avatar
      [interpreter] Remove special "prototype" load in class literals. · 5fdf5c1e
      mstarzinger authored 
      This allows us to remove the somewhat awkward BuildLoadObjectField
from the BytecodeGraphBuilder and also allows us to simplify the
bytecode stream for class literals.

R=oth@chromium.org

Review URL: https://codereview.chromium.org/1678103002

Cr-Commit-Position: refs/heads/master@{#33820}
      5fdf5c1e
    • mythria's avatar
      [Interpreter] Adds support for const/let variables to interpreter. · 90721a51
      mythria authored 
      Adds implementation and tests to support const/let variables in the
interpreter.

BUG=v8:4280,v8:4679
LOG=N

Review URL: https://codereview.chromium.org/1634153002

Cr-Commit-Position: refs/heads/master@{#33819}
      90721a51
    • bmeurer's avatar
      [runtime] Optimize and unify rest parameters. · 3ef573e9
      bmeurer authored 
      Replace the somewhat awkward RestParamAccessStub, which would always
call into the runtime anyway with a proper FastNewRestParameterStub,
which is basically based on the code that was already there for strict
arguments object materialization. But for rest parameters we could
optimize even further (leading to 8-10x improvements for functions with
rest parameters), by fixing the internal formal parameter count:

Every SharedFunctionInfo has a formal_parameter_count field, which
specifies the number of formal parameters, and is used to decide whether
we need to create an arguments adaptor frame when calling a function
(i.e. if there's a mismatch between the actual and expected parameters).
Previously the formal_parameter_count included the rest parameter, which
was sort of unfortunate, as that meant that calling a function with only
the non-rest parameters still required an arguments adaptor (plus some
other oddities). Now with this CL we fix, so that we do no longer
include the rest parameter in that count. Thereby checking for rest
parameters is very efficient, as we only need to check whether there is
an arguments adaptor frame, and if not create an empty array, otherwise
check whether the arguments adaptor frame has more parameters than
specified by the formal_parameter_count.

The FastNewRestParameterStub is written in a way that it can be directly
used by Ignition as well, and with some tweaks to the TurboFan backends
and the CodeStubAssembler, we should be able to rewrite it as
TurboFanCodeStub in the near future.

Drive-by-fix: Refactor and unify the CreateArgumentsType which was
different in TurboFan and Ignition; now we have a single enum class
which is used in both TurboFan and Ignition.

R=jarin@chromium.org, rmcilroy@chromium.org
TBR=rossberg@chromium.org
BUG=v8:2159
LOG=n

Review URL: https://codereview.chromium.org/1676883002

Cr-Commit-Position: refs/heads/master@{#33809}
      3ef573e9
  21. 05 Feb, 2016 4 commits
    • yangguo's avatar
      [interpreter] move the dispatch table off heap. · 91009c50
      yangguo authored 
      This makes the dispatch table similar to the builtins code list and makes
sure that the dispatch table does not move.

R=mstarzinger@chromium.org, rmcilroy@chromium.org

Review URL: https://codereview.chromium.org/1671813003

Cr-Commit-Position: refs/heads/master@{#33781}
      91009c50
    • mstarzinger's avatar
      [interpreter] Rename HandlerTable::depth field. · badaf79f
      mstarzinger authored 
      This makes the field in question more generic by renaming it from the
previous "depth" to "data". Pure refactoring, no function change.

R=rmcilroy@chromium.org,yangguo@chromium.org

Review URL: https://codereview.chromium.org/1670983003

Cr-Commit-Position: refs/heads/master@{#33779}
      badaf79f
    • yangguo's avatar
      [interpreter] source positions should not be emitted for dead code. · 85eff14c
      yangguo authored 
      R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1668863002

Cr-Commit-Position: refs/heads/master@{#33775}
      85eff14c
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      mvstanton authored 
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )

Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1670813005

Cr-Commit-Position: refs/heads/master@{#33766}
      3f36e658
  23. 04 Feb, 2016 6 commits
    • adamk's avatar
      Support computed properties for ES2015 Function.name · 21c045a2
      adamk authored 
      Adds a new runtime function, %DefineDataPropertyInLiteral, which
takes a fifth argument specifying whether the property and value
are syntactically such that the value is a function (or class)
literal that should have its name set at runtime.

The new runtime call also allows us to eliminate the now-redundant
%DefineClassMethod runtime function.

This should get much less ugly once we can desugar the "dynamic"
part of object literals in the parser (but that work is currently
blocked on having a performant way of desugaring literals).

BUG=v8:3699, v8:3761
LOG=n

Review URL: https://codereview.chromium.org/1626423003

Cr-Commit-Position: refs/heads/master@{#33756}
      21c045a2
    • oth's avatar
      [interpreter] Support for ES6 class literals. · 1b436ae1
      oth authored 
      Port of class literal support from the
ast-graph-builder implementation.

R=rmcilroy@chromium.org,mstarzinger@chromium.org
BUG=v8:4280,v8:4682
LOG=N

Review URL: https://codereview.chromium.org/1666943003

Cr-Commit-Position: refs/heads/master@{#33746}
      1b436ae1
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored 
      (RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1668103002

Cr-Commit-Position: refs/heads/master@{#33741}
      bb31db3a
    • yangguo's avatar
      [interpreter, debugger] implement debugger statement. · 86164a25
      yangguo authored 
      R=mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:4690
LOG=N

Review URL: https://codereview.chromium.org/1667073002

Cr-Commit-Position: refs/heads/master@{#33739}
      86164a25
    • mstarzinger's avatar
      [interpreter] Switch context during stack unwinding. · 76bfc16b
      mstarzinger authored 
      This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.

R=rmcilroy@chromium.org,bmeurer@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1665833002

Cr-Commit-Position: refs/heads/master@{#33733}
      76bfc16b
    • rmcilroy's avatar
      [Interpreter] Add explicit StackCheck bytecodes on function entry and back branches. · 1ce720f2
      rmcilroy authored 
      Moves the stack check from the function entry trampoline to instead be
after function activation using an explicit StackCheck bytecode. Also
add stack checks on back edges of loops.

BUG=v8:4280,v8:4678
LOG=N

Review URL: https://codereview.chromium.org/1665853002

Cr-Commit-Position: refs/heads/master@{#33730}
      1ce720f2