Skip to content

V
V8
Switch branch/tag
  1. 20 Jul, 2017 1 commit
  3. 17 Jul, 2017 1 commit
  5. 13 Jul, 2017 2 commits
  7. 07 Jul, 2017 1 commit
  9. 29 Jun, 2017 2 commits
  11. 27 Jun, 2017 2 commits
  13. 26 Jun, 2017 2 commits
  15. 23 Jun, 2017 3 commits
  17. 22 Jun, 2017 1 commit
    • kschimpf's avatar
      Fix use of history timers in background threads. · d4a10807
      kschimpf authored 
      HistoryTimer's can't run in the background because they use a timer
with a simple api of Start() and Stop(). This CL fixes this problem
by building a base class TimedHistogram that doesn't have a timer.

The class HistoryTimer is modified to use this base class so that
uses that run on the foreground thread do not need to be modified.

It also adds a new class TimedHistogramScope that defines the timer
in this class. This allows the corresopnding TimedHistogram class to
be type safe.

BUG=v8:6361

Review-Url: https://codereview.chromium.org/2929853003
Cr-Commit-Position: refs/heads/master@{#46150}
      d4a10807
  19. 20 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      Implement managed objects with phantom handles · f244f0c5
      Clemens Hammacher authored 
      For each Managed<T> (which is a Foreign), we create a weak global handle
with a finalizer which deletes the referenced C++ object once the
Foreign is dead.
Before calling this finalizer, the garbage collector needs to mark the
referenced object black (i.e. live), because the finalizer might
resurrect it.
Since this is never done for managed objects, we can use the more
lightweight phantom handle semantics, which allows the referenced
object to be garbage collected right away.

However, we can't access the global handle via the WeakCallbackInfo,
because the global handle will already be garbage collected. So we need
to store it explicitly. This is solved by storing the global handle
together with the finalizer.
In order to implement this, ownership of the ManagedObjectFinalizer
is moved from the isolate to the managed object.

R=ulan@chromium.org, mtrofin@chromium.org
BUG=v8:6505, chromium:734345

Change-Id: I94a245df601f70e19355d82439d30099e159231b
Reviewed-on: https://chromium-review.googlesource.com/539578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46036}
      f244f0c5
  21. 12 Jun, 2017 2 commits
    • Alexey Kozyatinskiy's avatar
      [inspector] introduced console.context · 701d79d0
      Alexey Kozyatinskiy authored 
      console.context(name:string) method returns console instance, this console instance fully implements console interface (including fact that any method can be called without console as receiver).
Protocol.Runtime.consoleAPICalled notification contains additional context:string field:
- "anonymous#unique-id" for any method call on unnamed console context,
- "name#unique-id" for any method call on named console context.

console.count and console.timeEnd have context as a scope.
console.clear clear all messages regardless on what context instance it was called.

console calls is ~10% slower with this CL since we need to store and then fetch console_context_id and console_context_name from function object.
We recently (in April) made console calls twice faster so 10% doesn't sound critical and existing of console.log call in hot code is problem by itself.

R=pfeldman@chromium.org

Bug: chromium:728767
Change-Id: I5fc73216fb8b28bfe1e8c2c1b393ebfbe43cd02e
Reviewed-on: https://chromium-review.googlesource.com/522128Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45864}
      701d79d0
    • Andreas Haas's avatar
      [wasm] Introduce a compilation manager for WebAssembly · 291f8dcf
      Andreas Haas authored 
      This CL is the first step in introducing a compilation manager for
asynchronous compile jobs in WebAssembly.

The compilation manager holds a list of currently active
AsyncCompileJobs. With the compilation manager these compile jobs get
deallocated when the isolate shuts down. Note that this CL is not enough
to provide a graceful isolate shutdown. For this we have to wait for all
compilation tasks to finish before we shut down, and we have to make the
tasks stateless. I plan to do these changes in separate CLs.

R=clemensh@chromium.org, mtrofin@chromium.org

BUG=v8:6436

Change-Id: I9a6e165dd2ef6d33944ca303fed49f7940eea7a2
Reviewed-on: https://chromium-review.googlesource.com/528079Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45858}
      291f8dcf
  23. 08 Jun, 2017 2 commits
    • kschimpf's avatar
      Localize counter class member functions. · f073a20b
      kschimpf authored 
      This CL takes advantage of the fact that StatsCounter is now local to
the Counters class. This includes:

1) Method StatsTable::SetCreateHistogramFunction() was only called in
one spot (in api.cc), which also called Counters::ResetHistograms()
and Counters::InitializeHistorgram(). InitializeHistogram can be
folded into Histogram.Reset().

2) Since Histogram::Reset() now regenerats the histogram, we no longer
need the field lookup_done_. Therefore there is no longer a race
between updating ptr_ and lookup_done_, making the Histogram class
thread safe.

3) Made the constructors of several classes private (except for class
Counters), minimizing the scope that they are used. When the couldn't
be moved, add comment that they were public only for test cases.

4) Removed the need for a mutex lock on StatsCounter::Reset(), since
it is now guaranteed to only be called when
StatsTable::SetCounterFunction() is called.

BUG=v8:6361
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

Review-Url: https://codereview.chromium.org/2918703002
Cr-Commit-Position: refs/heads/master@{#45791}
      f073a20b
    • Mythri's avatar
      [Turbofan] Simplify handling of hole check bytecodes in bytecode-graph-builder. · aed96e7b
      Mythri authored 
      ThrowIfHole bytecodes were handled by introducing deopt points to check
for a hole. To avoid deopt loops a hole check protector was used to
generate control flow if there was a deopt due to a hole. However, the
normal control flow version should be as fast as the deopt version
in general. The deopt version could potentially consume less compile time
but it may not be worth the complexity added. Hence simplifying it to
only construct the control flow.

Bug: v8:6383
Change-Id: Icace11f7a6e21e64e1cebd104496e3f559bc85f7
Reviewed-on: https://chromium-review.googlesource.com/525573Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45783}
      aed96e7b
  25. 06 Jun, 2017 4 commits
    • kschimpf's avatar
      Clean up issues raised on previous CL. · 9bc3bd4c
      kschimpf authored 
      Fixes issues raised in CL https://codereview.chromium.org/2887193002.
That is:

1) Remove using mutex in Isolate::InitializeCounters().

2) Use counters_shared_.get() instead of counters_ (and hence, also
   remove field counters_).

BUG=v8:6361

Review-Url: https://codereview.chromium.org/2919953003
Cr-Commit-Position: refs/heads/master@{#45743}
      9bc3bd4c
    • jgruber's avatar
      [coverage] Block coverage with support for IfStatements · b4241540
      jgruber authored 
      This CL implements general infrastructure for block coverage together with
initial support for if-statements.

Coverage output can be generated in lcov format by d8 as follows:

$ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
$ genhtml ~/simple-if.lcov -o ~/simple-if
$ chrome ~/simple-if/index.html

A high level overview of the implementation follows:

The parser now collects source ranges unconditionally for relevant AST nodes.
Memory overhead is very low and this seemed like the cleanest and simplest
alternative.

Bytecode generation uses these ranges to allocate coverage slots and insert
IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
for if-statements). The slot-range mapping is generated here and passed on
through CompilationInfo, and is later accessible through the
SharedFunctionInfo.

The IncBlockCounter bytecode fetches the slot-range mapping (called
CoverageInfo) from the shared function info and simply increments the counter.
We don't collect native-context-specific counts as they are irrelevant to our
use-cases.

Coverage information is finally generated on-demand through Coverage::Collect.
The only current consumer is a d8 front-end with lcov-style output, but the
short-term goal is to expose this through the inspector protocol.

BUG=v8:6000
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

Review-Url: https://codereview.chromium.org/2882973002
Cr-Commit-Position: refs/heads/master@{#45737}
      b4241540
    • Mythri's avatar
      [Interpreter] Introduce bytecodes that check for hole and throw. · c360c6a1
      Mythri authored 
      Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole 
/ ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
In the bytecode-graph builder they are handled by introducing a deopt point
instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
bytecodes are removed since they are no longer required.


Bug: v8:4280, v8:6383
Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
Reviewed-on: https://chromium-review.googlesource.com/509613
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45720}
      c360c6a1
    • Mircea Trofin's avatar
      [wasm] Remove support for overloading async APIs. · fc3cc3bc
      Mircea Trofin authored 
      This wraps up the move to explicit APIs, i.e.
instantiateStreaming/compileStreaming.

Bug: 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icc8280b2b3ad35acb90cc0beebe3acd7581179d7
Reviewed-on: https://chromium-review.googlesource.com/525141
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@{#45719}
      fc3cc3bc
  27. 02 Jun, 2017 1 commit
  29. 30 May, 2017 1 commit
  31. 24 May, 2017 3 commits
  33. 16 May, 2017 2 commits
    • Leszek Swirski's avatar
      [ignition] Change --trace-ignition to a runtime flag · 4becbe34
      Leszek Swirski authored 
      Generate the code (extra runtime calls) for --trace-ignition support at
compile time, based on a #define (similar to TRACE_MAPS). Then check for
--trace-ignition at run-time when deciding whether to actually print
anything. This should make --trace-ignition less painful to use.

Note that --trace-igition is disabled by default, even on debug builds.
It has to be enabled with the gn arg "v8_enable_trace_ignition=true"

As a drive-by, TRACE_MAPS is renamed to V8_TRACE_MAPS, for consistency,
and SFI unique index (needed both by --trace-ignition and --trace-maps)
is cleaned up to be behind another #define.

Change-Id: I8dd0c62d0e6b7ee9c75541d45eb729dc03acbee9
Reviewed-on: https://chromium-review.googlesource.com/506203
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45346}
      4becbe34
    • Jakob Kummerow's avatar
      [elements] Fix pathological slowness when deleting many elements · 6aaccd0f
      Jakob Kummerow authored 
      When most elements of an object are deleted, we want to normalize its
elements backing store to a dictionary in order to save space. Finding
the right time to do so should not incur a linear cost on each delete
operation. This patch changes the heuristic to an amortized-constant
approach based on a global counter and the current backing store
capacity.

BUG=chromium:542978

Change-Id: Ifdf29ab2211fdde1df9078f63be4118627d6a67e
Reviewed-on: https://chromium-review.googlesource.com/506191Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45330}
      6aaccd0f
  35. 15 May, 2017 1 commit
  37. 10 May, 2017 3 commits
  39. 09 May, 2017 2 commits
  41. 08 May, 2017 3 commits