Skip to content

V
V8
Switch branch/tag
  1. 05 Apr, 2016 3 commits
  3. 04 Apr, 2016 1 commit
  5. 30 Mar, 2016 1 commit
    • mythria's avatar
      [Interpreter] Adds support to fetch return value on break at return. · b82720df
      mythria authored 
      Debugger fetches the return value of a function when we break at return.
Interpreter holds the return value in accumulator. This is not stored in a
specified location on stack and hence it is not possible to look it up from
stack similar to full-codegen or optimized frames. This cl adds support to
store the value of accumulator on debug breaks. The value of accumulator is
passed to the runtime function and is then stored in thread local data.

Also changes full-codegen implementation to match that of ignition.
The return value from full-codegen is also stored in thread local data.
The return value is fetched directly thread local data instead of
finding it by iterating over frames.

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

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

Cr-Commit-Position: refs/heads/master@{#35127}
      b82720df
  7. 24 Mar, 2016 2 commits
    • machenbach's avatar
      Revert of [Interpreter] Adds support to fetch return value on break at return.... · 25d2b247
      machenbach authored 
      Revert of [Interpreter] Adds support to fetch return value on break at return. (patchset #9 id:160001 of https://codereview.chromium.org/1818873003/ )

Reason for revert:
[Sheriff] Seems to break nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/6019

Original issue's description:
> [Interpreter] Adds support to fetch return value on break at return.
>
> Debugger fetches the return value of a function when we break at return.
> Interpreter holds the return value in accumulator. This is not stored in a
> specified location on stack and hence it is not possible to look it up from
> stack similar to full-codegen or optimized frames. This cl adds support to
> store the value of accumulator on debug breaks. The value of accumulator is
> passed to the runtime function and is then stored in thread local data.
>
> Also changes full-codegen implementation to match that of ignition.
> The return value from full-codegen is also stored in thread local data.
> The return value is fetched directly thread local data instead of
> finding it by iterating over frames.
>
> BUG=v8:4280, v8:4690
> LOG=N
>
> Committed: https://crrev.com/fb65527b75754bcf3b173f16f5d0b04a1c6d9b99
> Cr-Commit-Position: refs/heads/master@{#35060}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,weiliang.lin@intel.com,balazs.kilvady@imgtec.com,jyan@ca.ibm.com,mythria@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4690

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

Cr-Commit-Position: refs/heads/master@{#35065}
      25d2b247
    • mythria's avatar
      [Interpreter] Adds support to fetch return value on break at return. · fb65527b
      mythria authored 
      Debugger fetches the return value of a function when we break at return.
Interpreter holds the return value in accumulator. This is not stored in a
specified location on stack and hence it is not possible to look it up from
stack similar to full-codegen or optimized frames. This cl adds support to
store the value of accumulator on debug breaks. The value of accumulator is
passed to the runtime function and is then stored in thread local data.

Also changes full-codegen implementation to match that of ignition.
The return value from full-codegen is also stored in thread local data.
The return value is fetched directly thread local data instead of
finding it by iterating over frames.

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

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

Cr-Commit-Position: refs/heads/master@{#35060}
      fb65527b
  9. 21 Mar, 2016 1 commit
    • oth's avatar
      [interpreter] Add support for scalable operands. · 48d082af
      oth authored 
      This change introduces wide prefix bytecodes to support wide (16-bit)
and extra-wide (32-bit) operands. It retires the previous
wide-bytecodes and reduces the number of operand types.

Operands are now either scalable or fixed size. Scalable operands
increase in width when a bytecode is prefixed with wide or extra-wide.

The bytecode handler table is extended to 256*3 entries. The
first 256 entries are used for bytecodes with 8-bit operands,
the second 256 entries are used for bytecodes with operands that
scale to 16-bits, and the third group of 256 entries are used for
bytecodes with operands that scale to 32-bits.

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

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

Cr-Commit-Position: refs/heads/master@{#34955}
      48d082af
  11. 15 Mar, 2016 1 commit
  13. 14 Mar, 2016 1 commit
    • hpayer's avatar
      [heap] Black allocation. · ad51e8b1
      hpayer authored 
      When black allocation is active, all objects allocated in old space are allocated black. Important: With that change, you cannot assume anymore that new objects are white right after their allocation. Currently, black allocation is enabled when incremental marking is started.

This feature can be turned off via flag: --noblack-allocation

BUG=chromium:561449
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34743}
      ad51e8b1
  15. 10 Mar, 2016 1 commit
  17. 08 Mar, 2016 1 commit
  19. 07 Mar, 2016 1 commit
  21. 02 Mar, 2016 1 commit
    • yangguo's avatar
      [debugger] Ensure at least one breakable position per function. · 44e9622a
      yangguo authored 
      The function literal consists of a list of statements. Each statement
is associated with a statement position including break location. The
only exception to this rule is when the function immediately throws if
scope resolution found an illegal redeclaration. Make sure that we add a
break location for this case as well. The debugger relies on this.

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

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

Cr-Commit-Position: refs/heads/master@{#34422}
      44e9622a
  23. 01 Mar, 2016 1 commit
    • yangguo's avatar
      [debugger] fix break locations for assignments and return. · d9fe836d
      yangguo authored 
      We used to emit debug break location on block entry. This cannot be
ported to the interpreted as we do not emit bytecode for block entry.
This made no sense to begin with though, but accidentally added
break locations for var declarations.

With this change, the debugger no longer breaks at var declarations
without initialization. This is in accordance with the fact that the
interpreter does not emit bytecode for uninitialized var declarations.

Also fix the bytecode to match full-codegen's behavior wrt return
positions:
- there is a break location before the return statement, with the source
  position of the return statement.
- right before the actual return, there is another break location. The
  source position points to the end of the function.

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

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

Cr-Commit-Position: refs/heads/master@{#34388}
      d9fe836d
  25. 25 Feb, 2016 2 commits
  27. 24 Feb, 2016 3 commits
  29. 23 Feb, 2016 1 commit
  31. 22 Feb, 2016 1 commit
  33. 17 Feb, 2016 1 commit
  35. 11 Feb, 2016 1 commit
  37. 10 Feb, 2016 1 commit
  39. 05 Feb, 2016 3 commits
    • 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
    • zhengxing.li's avatar
      [debugger] Use code offsets from frame summary in FromFrame Function. · a0f6d5ed
      zhengxing.li authored 
      The CL 33579 (https://codereview.chromium.org/1618343002) use code offsets instead of raw PC where possible.

But the offset maybe come from an optimized frame, not the un-optimized frame that FromCodeOffset and BreakIndexFromCodeOffset function expect.
So The offset from optimized frame can't be used in FromCodeOffset and  BreakIndexFromCodeOffset function.

This CL use the frame summary to find the corresponding code offset in unoptimized code according to Yang's suggestion.

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

Cr-Commit-Position: refs/heads/master@{#33778}
      a0f6d5ed
    • 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
  41. 04 Feb, 2016 1 commit
    • 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
  43. 28 Jan, 2016 1 commit
  45. 27 Jan, 2016 2 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      mvstanton authored 
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

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

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

Cr-Commit-Position: refs/heads/master@{#33556}
      a7027851
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      mvstanton authored 
      (Fixed a bug found by nosnap builds.)

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

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

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

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33548}
      d984b3b0
  47. 26 Jan, 2016 3 commits
    • yangguo's avatar
      [debugger] muting break positions should work for the entire statement. · 8349ee0c
      yangguo authored 
      A statement could have several break positions. The entire statement
should be considered muted if break points across all these break
positions evaluate to false.

R=verwaest@chromium.org
BUG=chromium:429167
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33522}
      8349ee0c
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored 
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

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

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

Cr-Commit-Position: refs/heads/master@{#33520}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored 
      We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

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

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

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33518}
      a5200f7e
  49. 21 Jan, 2016 1 commit
  51. 14 Jan, 2016 1 commit
  53. 18 Dec, 2015 1 commit
  55. 16 Dec, 2015 2 commits
    • yangguo's avatar
      [debugger] simplify step over recursive function call. · 2bb6e197
      yangguo authored 
      The problem is this: when stepping over a recursive function call,
the recursive function is flooded with one-shot break points so that
we break after the call, but since the callee is the same function,
the callee is also flooded, resulting a break in the callee. That
however would have been a "step in" instead of "step over".

The original solution was to recognize this by comparing FP. If we
end up in Debug::Break, we still have to check the current FP against
the remembered FP to see whether we are on the same stack height.
If we are deeper, then it's not a "step over", and we do not trigger
a debug break event. In that case, we queue up the step-over, and
temporarily step out until we hit the desired stack height. Note that
in order to step out, we flood the caller, which in our example is
the same function as the callee. So we break at every flooded break
location, and comparing with FP to make sure we stepped out prevents
us from triggering debug break events.

The new solution simply ignores breaks when the FP compare fails.
We simply carry on until we hit a break where the FP compare succeeds.
There is no need to do a step out. The number of calls to Debug::Break
that do not trigger a debug break event due to failing FP compare is
the same. But the code is a lot easier to read.

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32897}
      2bb6e197
    • yangguo's avatar
      [debugger] remove some dead code. · b68f7e4c
      yangguo authored 
      credits to gcov.

R=cbruni@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32877}
      b68f7e4c