Skip to content

V
V8
Switch branch/tag
  1. 19 Jun, 2017 2 commits
  3. 17 Jun, 2017 1 commit
  5. 16 Jun, 2017 19 commits
  7. 15 Jun, 2017 9 commits
    • Adam Klein's avatar
      Revert "[builtins] Move most WeakMap/WeakSet code from JS to C++ builtins" · 431abca0
      Adam Klein authored 
      This reverts commit 8196e102.

Reason for revert: Performance regression due to hashcode lookup.

Original change's description:
> [builtins] Move most WeakMap/WeakSet code from JS to C++ builtins
> 
> They were already implemented mostly in C++ (only error/negative
> cases were handled in script), so this is mostly just a cleanup.
> Only the constructors remain in script after this CL.
> 
> Bug: v8:6354
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
> Reviewed-on: https://chromium-review.googlesource.com/531670
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45924}

TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org
Bug: v8:6354, chromium:733238
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng

Change-Id: Ia5a741b9587886298f3ca057f6a6adeba556b8e0
Reviewed-on: https://chromium-review.googlesource.com/537207Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45966}
      431abca0
    • Sathya Gunasekaran's avatar
      [parser] Better error message when destructuring against undefined/null · bc2c785c
      Sathya Gunasekaran authored 
      Previously, when destructuring against null or undefined we would
print:

  d8> var { x } = null
  (d8):1: TypeError: Cannot match against 'undefined' or 'null'.
  var { x } = null
  ^
  TypeError: Cannot match against 'undefined' or 'null'.
      at (d8):1:1


The above message uses the term "match" which isn't a common term in
JavaScript to describe destructuring. This message also doesn't
provide the name of the property that fails destructuring.

This patch changes the error message to be:

  d8> var { x } = null;
  (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
  var { x } = null;
        ^
  TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
      at (d8):1:1

This patch changes the message to say "destructure" instead of "match".

This patch adds support for printing property names that are string
literals. We iterate through every property and pick the first string
literal property name if it exists. This provides at least some
feedback to the developer.

This patch also makes the pointer point to the position of the
property name that fails destructuring.

For computed and numeric property names, we print a generic error:
  d8> var { 1: x } = null
  (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'.
  var { 1: x } = null
  ^
  TypeError: Cannot destructure against 'undefined' or 'null'.
      at (d8):1:1

Bug: v8:6499
Change-Id: I35b1ac749489828686f042975294b9926e2dfc53
Reviewed-on: https://chromium-review.googlesource.com/537341Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45965}
      bc2c785c
    • Adam Klein's avatar
      [bootstrapper|cleanup] Simplify creation of Atomics object · 390ad8c5
      Adam Klein authored 
      The Atomics object is a normal object, just like Math, JSON, etc., so
we should be able to set it up in the same way those are set up
since cff5470a.

Change-Id: I46a9ba990707c0659f1a62f628b2c69204e536f8
Reviewed-on: https://chromium-review.googlesource.com/537076Reviewed-by: 's avatarBen Smith <binji@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45964}
      390ad8c5
    • Adam Klein's avatar
      [cleanup] Modernize creation of JSON, Math, and Intl objects · cff5470a
      Adam Klein authored 
      Before this patch, those builtin objects all used a strange-looking
pattern for creation that involved creating a new constructor
function (likely in order to get their ES5 [[Class]] set
appropriately).

But in modern times, with @@toStringTag as the mechanism of returning
the correct toString value, there should be no need for those extra
hoops, so simply use the Object constructor instead.

Change-Id: Id841dace26bf71f73ec25a71f1297d502438b27c
Reviewed-on: https://chromium-review.googlesource.com/533922
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45963}
      cff5470a
    • Adam Klein's avatar
      [runtime|cleanup] Remove implementation of unreachable runtime functions · 405fafb8
      Adam Klein authored 
      Change-Id: Ie4d21d2fc10db40efb42d66c9438ce3f3f01ce79
Reviewed-on: https://chromium-review.googlesource.com/533804Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45962}
      405fafb8
    • Georg Neis's avatar
      [modules] Fix setting variables via debug-scopes. · e53fdff9
      Georg Neis authored 
      I incorrectly assumed that ScopeIterator::SetModuleVariableValue gets called
when the frame is the module function.

R=jgruber@chromium.org, kozyatinskiy@chromium.org

Bug: v8:1569, v8:6484
Change-Id: I1fbad8ccde57280149547c78e679527f7a0c89dd
Reviewed-on: https://chromium-review.googlesource.com/535620Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45961}
      e53fdff9
    • Leszek Swirski's avatar
      Revert "[frames] Make interpreted frame detection stricter (reland)" · 920796b3
      Leszek Swirski authored 
      This reverts commit b7a036a6.

Reason for revert: We don't want to ever access the heap when walking the stack

Original change's description:
> [frames] Make interpreted frame detection stricter (reland)
> 
> When iterating over stack frames, make the interpreted frame detection
> require that the frame header contains the bytecode array.
> 
> Currently, the stack frame iterator supports bytecode handlers that
> don't create stack frames by checking if the top of the stack (i.e. the
> return address) is the interpreter entry trampoline. However, optimized
> code tail called from the interpreter entry trampoline can move the
> stack pointer without clearing the stack, which means it can end up with
> a pointer into the interpreter entry trampoline on the top of its stack
> (in an uninitialized value), and be interpreted as an interpreted frame.
> 
> To avoid such optimized code frames being interpreted as interpreted
> frames, we now additionally test the frame header, to see if it contains
> a valid pointer to a BytecodeArray.
> 
> Reland of https://chromium-review.googlesource.com/c/535646/
> 
> Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
> Reviewed-on: https://chromium-review.googlesource.com/536935
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45959}

TBR=kozyatinskiy@chromium.org,leszeks@chromium.org

Change-Id: I52a62c8e11af4d1565af92f10113b955f8c2c2f2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/536938Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45960}
      920796b3
    • Leszek Swirski's avatar
      [frames] Make interpreted frame detection stricter (reland) · b7a036a6
      Leszek Swirski authored 
      When iterating over stack frames, make the interpreted frame detection
require that the frame header contains the bytecode array.

Currently, the stack frame iterator supports bytecode handlers that
don't create stack frames by checking if the top of the stack (i.e. the
return address) is the interpreter entry trampoline. However, optimized
code tail called from the interpreter entry trampoline can move the
stack pointer without clearing the stack, which means it can end up with
a pointer into the interpreter entry trampoline on the top of its stack
(in an uninitialized value), and be interpreted as an interpreted frame.

To avoid such optimized code frames being interpreted as interpreted
frames, we now additionally test the frame header, to see if it contains
a valid pointer to a BytecodeArray.

Reland of https://chromium-review.googlesource.com/c/535646/

Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
Reviewed-on: https://chromium-review.googlesource.com/536935Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45959}
      b7a036a6
    • v8-autoroll's avatar
      Update V8 DEPS. · 8f741221
      v8-autoroll authored 
      Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4280b28..3ab6155

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/597f96e..59a182b

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: Idaf4f74956b999fe846a21efb85850e50e619bbb
Reviewed-on: https://chromium-review.googlesource.com/536514Reviewed-by: 's avatarv8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45958}
      8f741221
  9. 14 Jun, 2017 9 commits
    • jshin's avatar
      Use ICU for ID_START, ID_CONTINUE and WhiteSpace check · 4aeb94a4
      jshin authored 
      Use ICU to check ID_Start, ID_Continue and WhiteSpace even for BMP
when V8_INTL_SUPPORT is on (which is default).

Change LineTerminator::Is() to check 4 code points from
ES#sec-line-terminators instead of using tables and Lookup function.

Remove Lowercase::Is(). It's not used anywhere.

Update webkit/{ToNumber,parseFloat}.js to have the correct expectation
for U+180E and the corresponding expected files. This is a follow-up to
an earlier change ( https://codereview.chromium.org/2720953003 ).

CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng

BUG=v8:5370,v8:5155
TEST=unittests --gtest_filter=CharP*
TEST=webkit: ToNumber, parseFloat
TEST=test262: built-ins/Number/S9.3*, built-ins/parse{Int,Float}/S15*
TEST=test262: language/white-space/mong*
TEST=test262: built-ins/String/prototype/trim/u180e
TEST=mjsunit: whitespaces

Review-Url: https://codereview.chromium.org/2331303002
Cr-Commit-Position: refs/heads/master@{#45957}
      4aeb94a4
    • Jaideep Bajwa's avatar
      PPC: [heap] Make write barrier safe for the concurrent marker. · 8e646bd0
      Jaideep Bajwa authored 
      Port bd3d091d

Original Commit Message:

    With concurrent marking the write barrier should trigger even if the
    object is black because the concurrent marker could have fetched
    object field before marking the object black.

R=ulan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:694255
LOG=N

Change-Id: I3e3b5b467ab3c2eca45ac8d85523c8af4f5f5d4b
Reviewed-on: https://chromium-review.googlesource.com/535736Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#45956}
      8e646bd0
    • Ulan Degenbaev's avatar
      [heap] Add trivial BodyDescriptorWeak for objects without weak fields. · 74aa3ad0
      Ulan Degenbaev authored 
      This patch also changes the visitor of BytecodeArray to use
BytecodeArray::BodyDescriptor.

BUG=chromium:733159

Change-Id: I2ac72c97ec51996b5b100c447b543895180f4f78
Reviewed-on: https://chromium-review.googlesource.com/535674Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45955}
      74aa3ad0
    • Leszek Swirski's avatar
      Revert "[frames] Make interpreted frame detection stricter" · 8b5fe28c
      Leszek Swirski authored 
      This reverts commit f577b2bb.

Reason for revert: Failure on https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20verify%20csa/builds/1978

Original change's description:
> [frames] Make interpreted frame detection stricter
> 
> When iterating over stack frames, make the interpreted frame detection
> require that the frame header contains the bytecode array.
> 
> Currently, the stack frame iterator supports bytecode handlers that
> don't create stack frames by checking if the top of the stack (i.e. the
> return address) is the interpreter entry trampoline. However, optimized
> code tail called from the interpreter entry trampoline can move the
> stack pointer without clearing the stack, which means it can end up with
> a pointer into the interpreter entry trampoline on the top of its stack
> (in an uninitialized value), and be interpreted as an interpreted frame.
> 
> To avoid such optimized code frames being interpreted as interpreted
> frames, we now additionally test the frame header, to see if it contains
> a BytecodeArray.
> 
> Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70
> Reviewed-on: https://chromium-review.googlesource.com/535646
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45951}

TBR=kozyatinskiy@chromium.org,leszeks@chromium.org

Change-Id: Icc009cf97b816f6c33574782ed9ab473387886c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/535478Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45954}
      8b5fe28c
    • Toon Verwaest's avatar
      Drop invalid DCHECK, hashes can be 0 · f719f772
      Toon Verwaest authored 
      Bug: chromiume:733118
Change-Id: Ic144342d86fc84bf5c4700cec357ac8f3c6b2cb3
Reviewed-on: https://chromium-review.googlesource.com/535522Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45953}
      f719f772
    • Michael Lippautz's avatar
      [heap] Fix adjusting of area end when shrinking large pages · 21389501
      Michael Lippautz authored 
      Bug: chromium:733059, chromium:724947
Change-Id: Id7abc22ee0975cd609cc06a02552f68e9e0077e8
Reviewed-on: https://chromium-review.googlesource.com/535596
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45952}
      21389501
    • Leszek Swirski's avatar
      [frames] Make interpreted frame detection stricter · f577b2bb
      Leszek Swirski authored 
      When iterating over stack frames, make the interpreted frame detection
require that the frame header contains the bytecode array.

Currently, the stack frame iterator supports bytecode handlers that
don't create stack frames by checking if the top of the stack (i.e. the
return address) is the interpreter entry trampoline. However, optimized
code tail called from the interpreter entry trampoline can move the
stack pointer without clearing the stack, which means it can end up with
a pointer into the interpreter entry trampoline on the top of its stack
(in an uninitialized value), and be interpreted as an interpreted frame.

To avoid such optimized code frames being interpreted as interpreted
frames, we now additionally test the frame header, to see if it contains
a BytecodeArray.

Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70
Reviewed-on: https://chromium-review.googlesource.com/535646Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45951}
      f577b2bb
    • Alexey Kozyatinskiy's avatar
      [inspector] expose module variables for Debugger.evaluateOnCallFrame method · c2a7550f
      Alexey Kozyatinskiy authored 
      Context::Lookup method should support Module variables.

Bug: chromium:717670
Change-Id: I58d3448b9048c7f9dd7ab8b720803b3503cf91ae
Reviewed-on: https://chromium-review.googlesource.com/519389
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45950}
      c2a7550f
    • Pierre Langlois's avatar
      [arm] Cleanup addrmod1 encoding and Operand class · 30a29fa2
      Pierre Langlois authored 
      This cleanup is the result of trying to modify the `Assembler::addrmod1` method
and realising it's very easy to break it. It handles three groups of
instructions with different operands and uses `r0` when a register is not used:

- General case:            rd, rn, (rm|rm shift #imm|rm shift rs)
- Comparison instructions:     rn, (rm|rm shift #imm|rm shift rs)
- Move instructions        rd,     (rm|rm shift #imm|rm shift rs)

Let's use `no_reg` instead of `r0` with explicit checks and assertions so that
it's clear this method is used with multiple types of instructions.
Additionaly, keep the order of operands as "rd", "rn", "rm".

As drive-by fixes, I've taken the opportunity to add a few helper methods to the
`Operand` class.

Bug: 
Change-Id: If8140d804bc90dea1d3c186b3cee54297f91462a
Reviewed-on: https://chromium-review.googlesource.com/531284
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45949}
      30a29fa2