Skip to content

V
V8
Switch branch/tag
  1. 27 Nov, 2017 7 commits
    • Michael Lippautz's avatar
      [heap] Move support for inner pointer lookups into heap/ · 9af72045
      Michael Lippautz authored 
      The GcSafe* methods rely on Heap internals and should thus belong to Heap.

Bug: 
Change-Id: I4e6468d51c4dda1d10e94568698e05bee1b56b40
Reviewed-on: https://chromium-review.googlesource.com/789935
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49630}
      9af72045
    • Ivica Bogosavljevic's avatar
      Fix compilation failures with GCC 6.3.0 · 70dbac4b
      Ivica Bogosavljevic authored 
      Bug: 
Change-Id: If2468dab0ce2ef59a1f9cc8e4d8dc57b320f8c5f
Reviewed-on: https://chromium-review.googlesource.com/789041
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49629}
      70dbac4b
    • Sathya Gunasekaran's avatar
      [class] Store class fields initializer on the constructor · 4ca9d843
      Sathya Gunasekaran authored 
      Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:

- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.

- This synthetic variable could potentially resolve to an initializer
of an outer class.

For ex:
class X extends Object {
  c = 1;
  constructor() {
    var t = () => {
      class P extends Object {
        constructor() {
          var t = () => { super(); };
          t();
        }
      }
      super();
    }
    t();
  }
}

In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.

Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.

For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.

For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:

In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.

This is usually the common case and we don't pay any cost for not using
class fields.

(b) We are in a super() call inside an arrow function in the derived
constructor:

In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.

super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.

Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49628}
      4ca9d843
    • Yang Guo's avatar
      [gn] Add v8_monolith static library target. · 925ed598
      Yang Guo authored 
      R=machenbach@chromium.org

Bug: v8:6105
Change-Id: I51d7d38897d1b20469304345d11228a8f78d3489
Reviewed-on: https://chromium-review.googlesource.com/788376
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49627}
      925ed598
    • Michael Starzinger's avatar
      [heap] Bump maximum nesting level of memory modification scopes. · ffbbc492
      Michael Starzinger authored 
      This increases the maximum nesting level for memory modification scopes
from 3 to 4. It is a follow-up to WebAssembly optimizations which did
increase the total nesting in favor of performance. This also hoists
out the value into a constant, so that it is easier to change.

R=ahaas@chromium.org
BUG=v8:6792,chromium:787731

Change-Id: Ib60a7d66cdf42227d6b717a38c0923bcbbacf8dc
Reviewed-on: https://chromium-review.googlesource.com/788859Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49626}
      ffbbc492
    • Michael Lippautz's avatar
      [heap] Fix race when setting aborted compaction flag · 72702084
      Michael Lippautz authored 
      When compaction is aborted we used to remember this in a data structure
and in a flag on the page that was set by the compacting thread.

Setting the flag races with other threads recording old-to-old slots and
thus checking the page's flags.

Since we already record the page in a data structure, we can delay
setting the flag on the page until post processing aborted compaction
pages right after the evacuation phase.

Bug: v8:7125
Change-Id: I20d109f0f69cf8eab90ed355c113abc6a2f606da
Reviewed-on: https://chromium-review.googlesource.com/789931Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49625}
      72702084
    • Clemens Hammacher's avatar
      [ycm] Switch from gnu++11 to gnu++14 · 2457b385
      Clemens Hammacher authored 
      The chromium style guide allows the use of c++14 features
(https://chromium-cpp.appspot.com/).
Thus ycm should use c++14 by default.

R=bmeurer@chromium.org

Change-Id: I6eca99931d117ad57213e8c6e18e75d83b7fd675
Reviewed-on: https://chromium-review.googlesource.com/789873Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49624}
      2457b385
  3. 25 Nov, 2017 1 commit
  5. 24 Nov, 2017 13 commits
  7. 23 Nov, 2017 16 commits
  9. 22 Nov, 2017 3 commits
    • Mircea Trofin's avatar
      [wasm] Disable WasmCodeManagerTest when run under lsan · 4341749d
      Mircea Trofin authored 
      Disabling while investigating referenced bug.

Bug: chromium:787976
Change-Id: I0388d8902f40e3b2f3759542befd3c6c20b6da38
Reviewed-on: https://chromium-review.googlesource.com/786325
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49593}
      4341749d
    • Bill Budge's avatar
      [x64] Remove impossible TODO. · 8a58b487
      Bill Budge authored 
      - Removes TODO implying that moving a 32 bit immediate to a stack slot
  doesn't require the use of kScratchRegister. While movl can be used
  to store a 32 bit immediate to memory, it doesn't zero extend leaving
  part of the slot uninitialized.

Bug: 
Change-Id: I0ebc873b752d508753b624e0b5e262193a568c2b
Reviewed-on: https://chromium-review.googlesource.com/784193Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49592}
      8a58b487
    • Alexey Kozyatinskiy's avatar
      Reland [inspector] introduced stackTraceId and externalAsyncTask API · 885a5669
      Alexey Kozyatinskiy authored 
      Sometimes we need to capture stack trace on one debugger and use it
later as a parent stack on another debugger (e.g. worker.postMessage).

This CL includes following addition to our protocol and v8-inspector.h:
  - added Runtime.StackTraceId, this id represents stack trace captured
    on debugger with given id,
  - protocol client can fetch Runtime.StackTrace by
    Runtime.StacKTraceId using Debugger.getStackTrace method,
  - externalParent field is added to Debugger.paused event, it may
    contain external parent stack trace,
  - V8Inspector::storeCurrentStackTrace captures current stack trace
    and returns V8StackTraceId for embedder this id can be used as
    argument for V8Inspector::externalAsyncTaskStarted and
    V8Inspector::externalAsyncTaskFinished method. Any async stack
    trace captured between these calls will get passed external stack
    trace as external parent. These methods are designed to be called
    on different debuggers. If async task is scheduled and started on
    one debugger user should continue to use asyncTask* API,
  - Debugger.enable methods returns unique debuggerId.

TBR=dgozman@chromium.org,jgruber@chromium.org

Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4
Reviewed-on: https://chromium-review.googlesource.com/786274
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49591}
      885a5669