Commit Graph

1039 Commits

Author SHA1 Message Date
jgruber
b6bbfaec17 [coverage] Add support for jumps (Break,Continue,Return)
Drive-by-fixes: Singleton ranges past EOF, disable optimization
for block count mode.

Bug: v8:6000
Change-Id: I718891f8821285ce3d7d8360faaa91a43de5b93d
Reviewed-on: https://chromium-review.googlesource.com/541300
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46168}
2017-06-23 11:23:39 +00:00
Michael Achenbach
e65aeada27 Revert "Fix use of history timers in background threads."
This reverts commit d4a108078d.

Reason:
Fails on gpu bots:
https://build.chromium.org/p/client.v8.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/2145

# Fatal error in ../../v8/src/isolate.h, line 878
# Check failed: !IsIsolateInBackground().

BUG=v8:6361
TBR=kschimpf@chromium.org,cbruni@chromium.org,mtrofin@chromium.org,jochen@chromium.org,ulan@chromium.org

NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Change-Id: I5cf0241b3932b3c500598207b684a4b37936d0f8
Reviewed-on: https://chromium-review.googlesource.com/544825
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46154}
2017-06-23 06:36:19 +00:00
kschimpf
d4a108078d Fix use of history timers in background threads.
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}
2017-06-22 22:14:24 +00:00
Toon Verwaest
3568a433fb [runtime] Merge *NumberDictionary::Set and AtNumberPut
Bug: 
Change-Id: Idf5673ef3262c64d1c214362accc42554dbc2e69
Reviewed-on: https://chromium-review.googlesource.com/541340
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46090}
2017-06-21 13:28:32 +00:00
Clemens Hammacher
f244f0c5ef Implement managed objects with phantom handles
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: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46036}
2017-06-20 10:58:45 +00:00
Michael Starzinger
e47f37ebd0 [runtime] Fix detection of construct frames in stack traces.
This removes the heuristic from {JSStackFrame::IsConstructor} that tried
to infer whether a frame was called as a constructor or not from the
receiver value. We are now carrying along the appropriate bit derived
from the frame type instead.

R=jgruber@chromium.org
TEST=message/regress/regress-5727
BUG=v8:5727

Change-Id: I0e2f1d0f95485c84c4ebcd3cbfe0123c6afd2e01
Reviewed-on: https://chromium-review.googlesource.com/500313
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45972}
2017-06-16 09:27:36 +00:00
Andreas Haas
291f8dcfd5 [wasm] Introduce a compilation manager for WebAssembly
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/528079
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45858}
2017-06-12 12:46:42 +00:00
kschimpf
f073a20b69 Localize counter class member functions.
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}
2017-06-08 16:18:32 +00:00
Mythri
aed96e7b04 [Turbofan] Simplify handling of hole check bytecodes in bytecode-graph-builder.
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/525573
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45783}
2017-06-08 08:53:16 +00:00
danno
90c3a2d54b Inline Array.prototype.forEach in TurboFan
This CL contains a few pieces:

- A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
  graphs, which--when triggered--swizzle the values in the the FrameState to be
  parameters to a typically TF-generated builtin that resumes execution to finish
  the slow-case functionality.
- Continuation builtins that have special handling in the deoptimizer and their own
  new frame type to ensure that the values they need to begin executing can be stashed
  away and restored immediately before the builtin is called via a trampoline that runs
  when the continuation builtin's frame execution resumes.
- An implementation of Array.prototype.forEach in TurboFan that can be used to
  inline it. The inlined forEach implementation uses the checkpoints mechanism
  described above to deopt in the middle of the forEach in the cases that optimization
  invariants are violated. There is a slightly different continuation stub for each
  deopt point in the forEach implementation to ensure the correct side-effects, i.e.
  that the deopt of the builtin isn't programmatically observable.

Review-Url: https://codereview.chromium.org/2803853005
Cr-Commit-Position: refs/heads/master@{#45764}
2017-06-07 13:23:33 +00:00
kschimpf
9bc3bd4cdd Clean up issues raised on previous CL.
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}
2017-06-06 17:19:43 +00:00
Mythri
c360c6a1d0 [Interpreter] Introduce bytecodes that check for hole and throw.
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: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45720}
2017-06-06 09:41:31 +00:00
hpayer
502c6ae6a0 [heap] Activate memory reducer on external memory activity.
BUG=chromium:728228,chromium:626082
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

Review-Url: https://codereview.chromium.org/2917853004
Cr-Commit-Position: refs/heads/master@{#45671}
2017-06-02 09:40:16 +00:00
Clemens Hammacher
45618a9ab5 [wasm] Make prototype flags experimental
Most prototype implementations are not fully supported in the
interpreter. This is the case at least for exception handling, simd, and
atomics. Any function can be redirected to the interpreter though,
either by passing --wasm-interpret-all, or by dynamically redirecting to
the interpreter for debugging.
Making the flags experimental keeps the fuzzer from playing around with
these flags.

Drive-by: Refactor tests which explicitly set the prototype flag to use
a new scope for that.

R=ahaas@chromium.org
BUG=chromium:727584

Change-Id: I67da79f579f1ac93c67189afef40c6524bdd4430
Reviewed-on: https://chromium-review.googlesource.com/519402
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45639}
2017-05-31 14:18:08 +00:00
Jochen Eisinger
d41fe9f592 Replace PREPARE_FOR_EXECUTION_WITH_CONTEXT_IN_RUNTIME_CALL_STATS_SCOPE
Use the appropriate ENTER_V8* macros instead

BUG=v8:5830
R=marja@chromium.org

Change-Id: I85d7ae69830f6bad4f7057c4a646906846a1baa0
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/517793
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45612}
2017-05-30 17:37:41 +00:00
jgruber
0930a9243a [builtins] Add --print-builtin-size flag
Passing --print-builtin-size will print the size of all builtins on
isolate creation.

BUG=v8:5737

Review-Url: https://codereview.chromium.org/2895163002
Cr-Commit-Position: refs/heads/master@{#45605}
2017-05-30 14:14:32 +00:00
ulan
23cc6be3fc Rename "NoBarrier" memory operations to "Relaxed".
This is consistent with C++ memory model and avoids confusion with GC
write barrier.

BUG=

Review-Url: https://codereview.chromium.org/2912773002
Cr-Commit-Position: refs/heads/master@{#45584}
2017-05-30 07:44:37 +00:00
kschimpf
2a9965bd0e Move StatsTable into the Counters class.
By moving StatsTable from class Isolate to class Counters, it make the
class StatsTable thead safe. This is needed because these two classes
call each other, and for background compilation, instances of the
Counters class can persist longer that the corresponding Isolate it
came from.

It also removes unnecessary hops to the the Isolate, and checks if the
StatsTable has been created, for these communications.

BUG=v8:6361

Review-Url: https://codereview.chromium.org/2906063002
Cr-Commit-Position: refs/heads/master@{#45576}
2017-05-29 18:18:25 +00:00
Jochen Eisinger
68aa1ab388 Update module APIs to return Maybe<bool>
All APIs that can throw exceptions should return Maybe<> values

BUG=none
R=neis@chromium.org,gsathya@chromium.org

Change-Id: I6a6e5888cd71257bb02bdcfcc587c909d0c1d8f4
Reviewed-on: https://chromium-review.googlesource.com/517785
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45557}
2017-05-29 12:29:43 +00:00
kschimpf
fbbc0ff243 Create a thread safe version of StatsCounters and use.
Creates a new class StatsCounterThreadSafe to be used by counters that
can be updated when compiling/decoding etc. are done using workers.

Does this by using a mutex on all opreations.

Also updates the StatsCounterThreadSafe constructor to force counter
initialization, as well as method Reset(). In addition, whenever the
method StatsTable::SetCounterFunction() is called (from the main
thread), it forces counter initialization for all thread safe stats
counters.

BUG=v8:6361

Review-Url: https://codereview.chromium.org/2887193002
Cr-Commit-Position: refs/heads/master@{#45526}
2017-05-24 21:21:04 +00:00
Sathya Gunasekaran
aca3c14f15 [collections] Port Map constructor to CSA
Bug: v8:5717, v8:6354
Change-Id: I4be80eabcb0f98446e695a2ab1ad5804b7181ac7
Reviewed-on: https://chromium-review.googlesource.com/506818
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45489}
2017-05-23 13:21:47 +00:00
machenbach
3d40a47a9d Revert of [es2015] Precompute the descriptive string for symbols. (patchset #3 id:40001 of https://codereview.chromium.org/2900703002/ )
Reason for revert:
Speculative revert for:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/8901

Original issue's description:
> [es2015] Precompute the descriptive string for symbols.
>
> Previously the String constructor and the Symbol.prototype.toString
> methods had to compute the descriptive string for a Symbol on the fly,
> which can produce a lot of garbage when this happens a lot, i.e. when
> the String representation of a Symbol is used often. Now instead of
> doing this on-demand we can just do it upfront when creating the Symbol.
>
> That way we also ensure that we won't throw an exception when accessing
> the descriptive string of a Symbol, due to potential String length
> overflow, but have the exception during Symbol creation upfront, which
> is a lot less surprising behavior.
>
> BUG=v8:6278,v8:6344,v8:6350
> TBR=mlippautz@chromium.org
> R=ishell@chromium.org
>
> Review-Url: https://codereview.chromium.org/2900703002
> Cr-Commit-Position: refs/heads/master@{#45479}
> Committed: e87573822e

TBR=ishell@chromium.org,mlippautz@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6278,v8:6344,v8:6350

Review-Url: https://codereview.chromium.org/2903533002
Cr-Commit-Position: refs/heads/master@{#45483}
2017-05-23 11:58:15 +00:00
bmeurer
e87573822e [es2015] Precompute the descriptive string for symbols.
Previously the String constructor and the Symbol.prototype.toString
methods had to compute the descriptive string for a Symbol on the fly,
which can produce a lot of garbage when this happens a lot, i.e. when
the String representation of a Symbol is used often. Now instead of
doing this on-demand we can just do it upfront when creating the Symbol.

That way we also ensure that we won't throw an exception when accessing
the descriptive string of a Symbol, due to potential String length
overflow, but have the exception during Symbol creation upfront, which
is a lot less surprising behavior.

BUG=v8:6278,v8:6344,v8:6350
TBR=mlippautz@chromium.org
R=ishell@chromium.org

Review-Url: https://codereview.chromium.org/2900703002
Cr-Commit-Position: refs/heads/master@{#45479}
2017-05-23 09:49:08 +00:00
Wiktor Garbacz
9a8efd8a4e [cleanup] Remove return after UNREACHABLE
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9
Reviewed-on: https://chromium-review.googlesource.com/507287
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#45458}
2017-05-22 13:10:01 +00:00
Leszek Swirski
4becbe345f [ignition] Change --trace-ignition to a runtime flag
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: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45346}
2017-05-16 16:11:14 +00:00
Mythri
96b0928939 Remove crankshaft flag.
Crankshaft flag and opt flag mostly serve the same purpose. Using 
crankshaft to mean use optimizing compiler is a bit confusing.
This cl: https://chromium-review.googlesource.com/c/490206/ fixes 
the tests to use opt instead of crankshaft flag.

One difference between --no-crankshaft and --no-opt would be that 
--no-opt would mean no optimizations at all where as with --no-crankshaft
would mean we can force optimizations using %OptimizeFunctionOnNextCall.

Bug: v8:6325
Change-Id: If17393ac5b6af4ea6e9a98e092f0261c2e0899c5
Reviewed-on: https://chromium-review.googlesource.com/490307
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45298}
2017-05-15 12:34:20 +00:00
Ross McIlroy
11a211ff1b Reland: [TypeFeedbackVector] Store optimized code in the vector
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.

Original patch by Michael Stanton <mvstanton@chromium.org>

BUG=v8:6246,chromium:718891
TBR=yangguo@chromium.org,ulan@chromium.org

Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6
Reviewed-on: https://chromium-review.googlesource.com/500134
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-10 15:04:35 +00:00
Ross McIlroy
fd749344bf Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector"
This reverts commit 662aa425ba.

Reason for revert: Crashing on Canary
BUG=chromium:718891

Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
> 
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
> 
> Original patch by Michael Stanton <mvstanton@chromium.org>
> 
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
> 
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}

TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246

Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
2017-05-08 20:57:30 +00:00
Ross McIlroy
662aa425ba Reland: [TypeFeedbackVector] Store optimized code in the vector
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.

Original patch by Michael Stanton <mvstanton@chromium.org>

BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org

Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
2017-05-04 11:21:59 +00:00
jkummerow
63a40cae7c Make Isolate::AddDetachedContext GC safe
CopyFixedArrayAndGrow can trigger GC, which can clean up
previous detached contexts, so storing the length of the
FixedArray across the allocation is unsafe.

BUG=v8:6282

Review-Url: https://codereview.chromium.org/2857633002
Cr-Commit-Position: refs/heads/master@{#45038}
2017-05-02 15:06:32 +00:00
Michael Achenbach
5fcf508e07 Revert "[TypeFeedbackVector] Store optimized code in the vector"
This reverts commit c5ad9c6d8e.

Reason for revert: Fails on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661

Original change's description:
> [TypeFeedbackVector] Store optimized code in the vector
> 
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
> 
> Original patch by Michael Stanton <mvstanton@chromium.org>
> 
> BUG=v8:6246
> 
> Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
> Reviewed-on: https://chromium-review.googlesource.com/476891
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45022}

TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6246

Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619
Reviewed-on: https://chromium-review.googlesource.com/493287
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45027}
2017-05-02 11:51:01 +00:00
Ross McIlroy
c5ad9c6d8e [TypeFeedbackVector] Store optimized code in the vector
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.

Original patch by Michael Stanton <mvstanton@chromium.org>

BUG=v8:6246

Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
Reviewed-on: https://chromium-review.googlesource.com/476891
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45022}
2017-05-02 11:20:23 +00:00
ulan
e671ed3610 Decouple root visitors from object visitors.
This patch adds a new interface called RootVisitor and changes the root
iteration functions to accept a RootVisitor instead of an ObjectVisitor.

Future CLs will change ObjectVisitor to provide the host object to all
visiting functions, which will bring it in sync with static visitors.

Having separate visitors for roots and objects removes ambiguity in
VisitPointers and reduces chances of forgetting to record slots.

This is intended as pure refactoring. All places that require behavior
change are marked with TODO and will addressed in future CLs.

BUG=chromium:709075

Review-Url: https://codereview.chromium.org/2801073006
Cr-Commit-Position: refs/heads/master@{#44852}
2017-04-25 13:32:18 +00:00
kozyatinskiy
fa1de6145f [inspector] deduplicate stack frames
Since we already have cache on V8 side we can introduce caching on inspector side. It will decrease memory consumption and reduce time which we spend for collecting stacks. See [1] for details.

[1] https://docs.google.com/a/google.com/document/d/13H1Pn6dekcwqlaYP26CfyyYGuL-U9LtUPWmt3TIpOag/edit?usp=sharing

BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2825903002
Cr-Commit-Position: refs/heads/master@{#44753}
2017-04-20 17:33:03 +00:00
kozyatinskiy
49d32849b3 [inspector] store v8:StackTrace as FixedArray
- creating JSArray and further setter and getter calls are slower then on fixed array.

BUG=v8:6189
R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2813773002
Cr-Commit-Position: refs/heads/master@{#44657}
2017-04-14 16:49:08 +00:00
kozyatinskiy
81bb72c11c [inspector] cache stack frame for call sites
Usually program doesn't contain a lot of different stack frames in collected stack trace.

BUG=v8:6189
R=yangguo@chromium.orr
TBR=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2788413004
Cr-Commit-Position: refs/heads/master@{#44622}
2017-04-12 18:33:20 +00:00
kozyatinskiy
2e4a687338 [v8] v8::StackTrace::AsArray returns correct array
After [1] we return JSArray with internal structs, we should return JSObjects instead.

[1] https://codereview.chromium.org/2789073002

BUG=v8:6189
R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2806373005
Cr-Commit-Position: refs/heads/master@{#44581}
2017-04-11 15:30:50 +00:00
gsathya
94283dcf44 [ESNext] Implement DynamicImportCall
This patch implements the runtime semantics of dynamic import.

We create a new ASTNode so that we can pass the JSFunction closure() to
the runtime function from which we get the script_url.

d8 implements the embedder logic required to load and evaluate the modules.

The API is mostly implemented as specified.

BUG=8:5785

Review-Url: https://codereview.chromium.org/2703563002
Cr-Commit-Position: refs/heads/master@{#44551}
2017-04-11 09:33:11 +00:00
Camillo Bruni
981faa1e37 [runtime] Use more parameters inPushCodeObjectsAndDie
Force passing arguments on the stack for PushCodeObjectsAndDie by using
more function arguments.

Change-Id: I7a2e825f3423946a03f5dd988c640a37709f32e3
Reviewed-on: https://chromium-review.googlesource.com/472747
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44523}
2017-04-10 13:52:53 +00:00
kozyatinskiy
c0c1d76028 [inspector] introduced StackFrame::IsWasm flag
We don't need to do any kind of translation for non-wasm frames. And we need this knowledge for lazy symbolization.
Capturing stack trace is ~7% faster.

BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2795103004
Cr-Commit-Position: refs/heads/master@{#44502}
2017-04-08 22:26:22 +00:00
jgruber
9ddfeafe94 [builtins] Introduce new TFC macro and auto-generate TFS descriptors
Split TFS builtins into

* TFC: TF builtins with stub linkage that use a custom interface descriptor
       (e.g. because of a non-standard return size or untagged arguments)
* TFS: the rest.

Automatically generate interface descriptors for TFS builtins to reduce
boilerplate involved in setting up stub calls. These are now as simple as
creating the TFS stub and using CSA::CallBuiltin, no extra work required.

BUG=v8:6116

Review-Url: https://codereview.chromium.org/2777203007
Cr-Commit-Position: refs/heads/master@{#44490}
2017-04-07 15:42:11 +00:00
jkummerow
5f9af1e7b5 Reland "[snapshot] Move builtins generation into mksnapshot"
and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).

Only the GN build is supported; the GYP build is maintained working
but does not support the feature.

Previously landed as 4782bc0df8 / r44412.

BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;

Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44489}
2017-04-07 13:31:29 +00:00
Caitlin Potter
e434d11ffe Reland "[builtins] don't inline calls for common Promise ops in async builtins"
InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.

This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.

This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.

BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org

Change-Id: I83e2f096782db685fe316dd071980cd8d696fe53
Reviewed-on: https://chromium-review.googlesource.com/469927
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44483}
2017-04-07 12:10:57 +00:00
Franziska Hinkelmann
c931820df4 Revert "[builtins] don't inline calls for common Promise ops in async builtins"
This reverts commit 9461fe249e.

Reason for revert: Breaks a test in Node.js: 
 parallel/test-util-inspect

=== release test-util-inspect ===                                              
Path: parallel/test-util-inspect
#
# Fatal error in , line 0
# unreachable code
#

==== C stack trace ===============================


Original change's description:
> [builtins] don't inline calls for common Promise ops in async builtins
> 
> InternalResolvePromise, InternalPromiseReject and
> InternalPerformPromiseThen generate quite a lot of code.
> 
> This change adds 3 new TF stubs which inline calls to these builtins.
> These stubs are invoked rather than inlining those operations listed
> above directly. This is done for Async Iteration builtins, as well as
> Async Function builtins. Promise builtins are left as they were, and
> continue to inline these calls.
> 
> This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
> release build.
> 
> BUG=v8:5855
> R=​gsathya@chromium.org, jgruber@chromium.org
> 
> Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
> Reviewed-on: https://chromium-review.googlesource.com/461269
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44445}

TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5855

Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
Reviewed-on: https://chromium-review.googlesource.com/469946
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44448}
2017-04-06 15:13:44 +00:00
Caitlin Potter
9461fe249e [builtins] don't inline calls for common Promise ops in async builtins
InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.

This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.

This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.

BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org

Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
Reviewed-on: https://chromium-review.googlesource.com/461269
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44445}
2017-04-06 14:14:58 +00:00
Camillo Bruni
4da08b7dff Push the top code objects onto the stack in PushStackTraceAndDie
Doing so will increase the likelyhood of getting the interesting code objects
into the mindump.

Change-Id: I6c6d06bbfe7ab8649139b1146bda0f9b3d679064
Reviewed-on: https://chromium-review.googlesource.com/468967
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44444}
2017-04-06 14:02:58 +00:00
kozyatinskiy
ba9fc3d7bc Revert of [snapshot] Move builtins generation into mksnapshot (patchset #8 id:160001 of https://codereview.chromium.org/2760233005/ )
Reason for revert:
I think that this CL breaks chromium compilation on windows with clang (). All other CLs in the list looks trivial and don't change test/unittest/BUILD.gn.

[42456/47924] CXX obj/v8/test/unittests/unittests/value-serializer-unittest.obj
[42457/47924] LINK unittests.exe unittests.exe.pdb
FAILED: unittests.exe unittests.exe.pdb
E:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./unittests.exe /PDB:./unittests.exe.pdb @./unittests.exe.rsp
bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::AddAllocationObserver(class v8::internal::AllocationObserver *)" (?AddAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z)

slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z)

bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::RemoveAllocationObserver(class v8::internal::AllocationObserver *)" (?RemoveAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z)

slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z)

./unittests.exe : fatal error LNK1120: 2 unresolved externals

Original issue's description:
> [snapshot] Move builtins generation into mksnapshot
>
> and out of the main library. This saves about 5% of binary size
> (800KB on x64, 373KB on android_arm).
>
> Only the GN build is supported; the GYP build is maintained working
> but does not support the feature.
>
> BUG=v8:6055
> CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
>
> Review-Url: https://codereview.chromium.org/2760233005
> Cr-Commit-Position: refs/heads/master@{#44412}
> Committed: 4782bc0df8

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

Review-Url: https://codereview.chromium.org/2803903002
Cr-Commit-Position: refs/heads/master@{#44422}
2017-04-05 23:53:11 +00:00
jkummerow
4782bc0df8 [snapshot] Move builtins generation into mksnapshot
and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).

Only the GN build is supported; the GYP build is maintained working
but does not support the feature.

BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;

Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44412}
2017-04-05 13:28:48 +00:00
vchigrin
ddb67ec9da Encode any deoptimizer entry in serialized data.
This removes kDeoptTableSerializeEntryCount heuristic constant.

Review-Url: https://codereview.chromium.org/2790573002
Cr-Commit-Position: refs/heads/master@{#44379}
2017-04-04 14:25:57 +00:00
Clemens Hammacher
d1b4d4fea6 [wasm] [interpreter] Fix GC issue
Make sure that we call the destructors on all embedded object by
replacing the WasmInterpreterInternals::Delete method by an actual
destructor. This way, the compiler automatically calls destructors on
all embedded objects, in particular the IdentityMap in the CodeMap.

This change also requires to release managed objects *before*
tearing down the heap, because the wasm interpreter, referenced via
Managed<>, contains global handles. When those are destroyed, the
isolate still needs to be intact.

Drive-by: Fix include guard in managed.h.

R=ahaas@chromium.org, ulan@chromium.org, mvstanton@chromium.org
BUG=v8:5822

Change-Id: I9a067f037e013c84e4d697a1e913b27c683bb529
Reviewed-on: https://chromium-review.googlesource.com/466187
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44368}
2017-04-04 10:39:57 +00:00
kozyatinskiy
dc662e5b74 [inspector] store stack frame in struct instead of JSObject
JSObject is slow: creating strings for keys and storing values by these keys after takes significant amount of time.
With this CL console methods (most of them collect top stack frame to calculate source location) are ~33% faster.
V8Debugger::captureStackTrace is ~50% faster.

BUG=v8:6189
R=yangguo@chromium.org
TBR=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2789073002
Cr-Commit-Position: refs/heads/master@{#44344}
2017-04-03 14:58:49 +00:00
Clemens Hammacher
701124db95 [wasm] [interpreter] Add stack overflow checks
Add a limit to the number of nested call frames in the C++ wasm
interpreter.
Both the size of the value stack as well as the size of the block stack
are limited per call frame. Thus, a limit on only the call frame stack
is enough to limit the overall memory consumption of one interpreter
instance.

R=ahaas@chromium.org
BUG=v8:5822

Change-Id: If9f7e547cd1d003bc2ae3c7586ece6b3cf3be587
Reviewed-on: https://chromium-review.googlesource.com/463486
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44296}
2017-03-31 09:22:56 +00:00
kozyatinskiy
29dc4898c8 [inspector] fixed crash in InternalPromiseHasUserDefinedRejectHandler
Method should be ready to symbols inside of queue_arr.

BUG=v8:6168
R=gsathya@chromium.org

Review-Url: https://codereview.chromium.org/2782893003
Cr-Commit-Position: refs/heads/master@{#44254}
2017-03-29 22:21:42 +00:00
mtrofin
5fdb5a148e [wasm] Override mechanism for wasm js APIs
V8 side mechanism for overriding the wasm js APIs.

We will use these to:
- implement the Chrome-side constraints on module size, and throw with more
actionable error messages, while preserving layering.
The old mechansms will be deleted once we update the Chrome side with
this new mechanism.

- implement Chrome-side .compile and .instantiate overrides accepting
Response objects.

We may want to evolve this mechanism into something more general, not
requiring V8 preparation, by replacing the v8-definition with embedder
provided definitions. We're currently exploring if we can expand
"Extras", for instance.

BUG=

Review-Url: https://codereview.chromium.org/2773063002
Cr-Commit-Position: refs/heads/master@{#44119}
2017-03-24 18:26:07 +00:00
Marja Hölttä
09050c8a96 [objects.h splitting] Move out FrameArray.
BUG=v8:5402
R=mstarzinger@chromium.org

Change-Id: I4220cd1d7907f9c353265aeab38ee53dcf6f56b6
Reviewed-on: https://chromium-review.googlesource.com/459541
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44112}
2017-03-24 17:38:13 +00:00
kozyatinskiy
760c56bddf [inspector] changed a way of preserving stepping between tasks
Indisputable profit:
- correct break location in next task (see tests),
- stepOver with async await never lands in random code (see related test and issue),
- inspector doesn't store current stepping state in debugger agent and completely trust V8 - step to new inspector-V8 design (I will finish design doc soon).
- willExecuteScript and didExecuteScript instrumentation could be removed from code base - reduce probability of future errors.
- finally - less code,
- stepping implementation in V8 makes another step to follow our stepping strategy (stepOut should do stepInto and break when exit current frame) (another one one page design doc based on @aandrey comment is coming),
- knowledge about existing of context groups is still inspector-only.

Disputable part is related to super rare scenario when in single isolate we have more then one context group id with enabled debugger agent:
- if one agent request break in own context (stepping, pause, e.t.c.) then we ignore all breaks in another agent. From one hand it looks like good: user clicks stepInto and they don't expect that execution could be paused by another instance of DevTools in unobservable from current DevTools way (second DevTools will get paused notification and run nested message loop). From another hand we shouldn't ignore breakpoints or debugger statement never. In general, I think that proposed behavior is rathe feature then issue.
- and disadvantage, on attempt to break in non-target context group id we just call StepOut until reach target context group id, step out call could deoptimize code in non related to current debugger agent context. But break could happens only in case of debugger stmt or breakpoint - sound like minor issue. Ignoring break on exception sounds like real issue but by module of rareness of this case I think we can ignore this.

Implementation details:
- when debugger agent request break for any reason it passes target context group id to V8Debugger - last agent requesting break is preferred.
- when V8Debugger gets BreakProgramRequested notification from V8, it checks current context group id against target context group id, if they match then just process break as usual otherwise makes StepOut action,
- debug.cc at the end of microtask if last_scheduled_action is StepOut, schedules StepIn and will break on first instruction in next task.

BUG=chromium:654022
R=dgozman@chromium.org,yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2748503002
Cr-Commit-Position: refs/heads/master@{#44034}
2017-03-22 16:20:54 +00:00
Clemens Hammacher
857ec7980b Add templatized GlobalHandles::Create method
The old method always returned a Handle<Object>, requiring an explicit
cast in the caller. This CL makes it return Handle<T> if called with a
T* as parameter.

Also, remove now redundant casts from callers.

R=bmeurer@chromium.org

Change-Id: I13cfb2f2e812e8582a9a1d9d6c8a5a24f40d0e79
Reviewed-on: https://chromium-review.googlesource.com/458376
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44012}
2017-03-22 10:33:22 +00:00
Clemens Hammacher
3214ccf39b [wasm] [interpreter] Allow different activations
This CL makes the interpreter reentrant by allowing different
activations to be live at the same time. The wasm interpreter keeps a
list of activations and stores the stack height at the start of each
activation. This information is used to unwind just one activation, or
show the right portion of the interpreter stack for each interpreter
entry frame.
The WasmDebugInfo object stores a mapping from frame pointer (of the
interpreter entry) to the activation id in order to identify the
activation based on the physical interpreter entry frame.

R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822

Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb
Reviewed-on: https://chromium-review.googlesource.com/453958
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43976}
2017-03-21 11:25:51 +00:00
yangguo
fa3f8c6fb0 [debug] refactor code coverage to use enum for mode.
This is in preparation of adding precise binary mode.

BUG=v8:5808

Review-Url: https://codereview.chromium.org/2765813002
Cr-Commit-Position: refs/heads/master@{#43974}
2017-03-21 11:08:36 +00:00
Clemens Hammacher
91852dffaa [wasm] [interpreter] Handle stack unwinding
If an exception is thrown and the wasm interpreter entry frame is
unwound, also the internal frames in the interpreter need to be unwound.
We did not do so before, leaving a corrupted internal state of the wasm
interpreter. Thus reusing it would fail.
This CL fixes this and adds a test which reenters a previously unwound
wasm interpreter. It checks that this works and the correct stack is
returned.
This test also requires support for calling an imported function which
throws, so this change is also included here.

R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822

Change-Id: I12fb843f7a371a4e618b4ac63ed3299667a03a82
Reviewed-on: https://chromium-review.googlesource.com/453938
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43937}
2017-03-20 14:07:19 +00:00
neis
94b088ca3c Disentangle assembler from isolate.
This is a first step towards moving Turbofan code generation off the main thread.

Summary of the changes:
- AssemblerBase no longer has a pointer to the isolate. Instead, its
  constructor receives the few things that it needs from the isolate (on most
  architectures this is just the serializer_enabled flag).
- RelocInfo no longer has a pointer to the isolate. Instead, the functions
  that need it take it as an argument.  (There are currently still a few that
  implicitly access the isolate through a HeapObject.)
- The MacroAssembler now explicitly holds a pointer to the isolate (before, it
  used to get it from the Assembler).
- The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
  it's not used at all in the Assemblers.
- A few architectures implemented parts of the Assembler with the help
  of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
  longer has the isolate, but the MacroAssembler still needs it, this doesn't
  work anymore.  Instead, these Assemblers now use a new PatchingAssembler.

BUG=v8:6048

Review-Url: https://codereview.chromium.org/2732273003
Cr-Commit-Position: refs/heads/master@{#43890}
2017-03-17 11:18:06 +00:00
Andreas Haas
87354ade6b [wasm] Remove the WasmTrapHelper
Since TrapIf has been implemented on all platforms, there is no need
anymore for the old WasmTrapHelper code. This CL also removes
TrapIf-specific tests.

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

Change-Id: Ic069598441b7bd63bde2e66f4e536abea5ecebe6
Reviewed-on: https://chromium-review.googlesource.com/452380
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43887}
2017-03-17 10:30:31 +00:00
Clemens Hammacher
2b3fbd8208 Cleanup Isolate::UnwindAndFindHandler
Before adding stack unwinding of interpreted wasm frames, clean up the
respective method a bit.
Replace if-cascade by a switch, and inline the (previously public)
RemoveMaterializedObjectsOnUnwind method.

R=mstarzinger@chromium.org, jarin@chromium.org
BUG=v8:5822

Change-Id: Icf80c4adadc2f43551656ced8e92a67752d5c471
Reviewed-on: https://chromium-review.googlesource.com/453898
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43860}
2017-03-16 12:03:00 +00:00
Clemens Hammacher
7f460012c6 [wasm] Show interpreted frames on captured stack traces
In Isolate::CaptureSimpleStackTrace, we were ignoring interpreter entry
frames so far. This CLs changes this to gets the interpreted stack from
the wasm interpreter and add the frames to the FrameArray.

R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822

Change-Id: I705909532ff28af412ff809da94522866eaa1c0d
Reviewed-on: https://chromium-review.googlesource.com/452378
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43772}
2017-03-14 10:23:20 +00:00
eholk
118c376fcb [wasm] Initial signal handler
This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.

The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.

This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.

When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.

Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Original-Commit-Position: refs/heads/master@{#43523}
Committed: a5af7fe9ee
Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Commit-Position: refs/heads/master@{#43755}
Committed: 338622d7ca
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43759}
2017-03-13 22:12:23 +00:00
eholk
aba151b92f Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of https://codereview.chromium.org/2371833007/ )
Reason for revert:
ASAN breakage, such as https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/19111/steps/Check/logs/grow-memory

Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Original-Commit-Position: refs/heads/master@{#43523}
> Committed: a5af7fe9ee
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43755}
> Committed: 338622d7ca

TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2744383002
Cr-Commit-Position: refs/heads/master@{#43757}
2017-03-13 20:03:25 +00:00
eholk
338622d7ca [wasm] Initial signal handler
This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.

The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.

This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.

When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.

Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Commit-Position: refs/heads/master@{#43523}
Committed: a5af7fe9ee
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43755}
2017-03-13 19:14:35 +00:00
Sathya Gunasekaran
36a22fe775 [debug] Add exception predictions to builtins where missing.
This fixes the catch predictions for the following builtins --
AsyncFunctionAwaitCaught
AsyncFunctionAwaitUncaught
PromiseResolveClosure
ResolvePromise
PromiseResolve

Added tests for each.

Added whitelist for builtins behind a flag.

BUG=chromium:691875

Change-Id: I816cafdb69f0c9f1eefc440a0a44c36713d0b7dc
Reviewed-on: https://chromium-review.googlesource.com/450894
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43725}
2017-03-10 17:44:51 +00:00
Camillo Bruni
9ac64ca191 [api] Add v8::Isolate::DumpAndResetStats
Chrome no longer calls v8::Isolate::Dispose on shutdown, essentially preventing
the use of V8 stats within chrome/content_shell. This CL adds a basic hook to
the api that is then used to only print the stats.

Chrome change: https://codereview.chromium.org/2693353002

Change-Id: I1481c14afe611e9c08ae67c815201a45940daa57
Reviewed-on: https://chromium-review.googlesource.com/452338
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43706}
2017-03-09 17:30:42 +00:00
bmeurer
0b3e554e03 Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of https://codereview.chromium.org/2371833007/ )
Reason for revert:
Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory

Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43523}
> Committed: a5af7fe9ee

TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2723133003
Cr-Commit-Position: refs/heads/master@{#43525}
2017-03-01 19:47:27 +00:00
eholk
a5af7fe9ee [wasm] Initial signal handler
This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.

The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.

This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.

When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.

Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43523}
2017-03-01 18:02:13 +00:00
Marja Hölttä
83849da70f [iwyu] Pre-work for removing unallowed include macro-assembler.h -> assembler-inl.h
BUG=v8:5294

Change-Id: If45f25aae8de526027b7851cb4efe0ccf4a7c4b1
Reviewed-on: https://chromium-review.googlesource.com/444226
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43388}
2017-02-23 12:10:21 +00:00
mtrofin
caa1d4b262 [wasm] Managed<T> ensures T's lifetime does not leak past Isolate's
Native resources allocated by v8, as internal implementation detail,
and held by a Foreign object, must be released when the Isolate is
torn down. Example: wasm::WasmModule allocated by wasm compile, and
held throughout the lifetime of the WebAssembly.Module object.

This change:
- Extends Managed<CppType> with a mechanism for doing just that
- Separates the role of Managed<CppType> to be strictly an owner of
the lifetime of the native resource. For cases where that's not
desirable, we can polymorphically use Foregin.
- moves managed.h out of wasm, since it's not wasm-specific.

BUG=680065

Review-Url: https://codereview.chromium.org/2676513008
Cr-Commit-Position: refs/heads/master@{#43350}
2017-02-21 17:23:38 +00:00
bmeurer
1a2362089c [es2015] Remove the @@hasInstance protector cell.
We cannot skip the @@hasInstance lookup in instanceof depending on a
global protector cell, as the lookup of the property is observable
via proxies or accessors. So remove the global protector and properly
implement CSA::InstanceOf via GetPropertyStub, with an appropriate
fast-path for Function.prototype[@@hasInstance] where we call the
builtin code object directly if the function matches, skipping all
the checks from the call sequence, and also avoid the redundant
ToBoolean conversion on the result.

R=yangguo@chromium.org
TBR=ulan@chromium.org
BUG=v8:5958

Review-Url: https://codereview.chromium.org/2684033012
Cr-Commit-Position: refs/heads/master@{#43137}
2017-02-13 07:16:27 +00:00
gsathya
31bc17f006 [promises] cleanup default promise handlers
Use private symbols to mark default promise handler, instead of calling out to default
handlers defined in JS. We check for this symbol in PromiseHandle and perform the
appropriate behavior as the default handlers.

Catch prediction logic is updated to account for a symbol.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2695593002
Cr-Commit-Position: refs/heads/master@{#43135}
2017-02-13 06:31:11 +00:00
mlippautz
e03a220611 [heap] Remove dead counters and move regexp code counter to Isolate
BUG=

Review-Url: https://codereview.chromium.org/2684233004
Cr-Commit-Position: refs/heads/master@{#43094}
2017-02-10 12:32:01 +00:00
Jochen Eisinger
83c2545356 Use correct printf format macros for size_t printing
R=mlippautz@chromium.org
BUG=

Change-Id: I4b25bcc1accd652e28a1fe4fc9776265afa1b75b
Reviewed-on: https://chromium-review.googlesource.com/440944
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43084}
2017-02-10 09:10:12 +00:00
yangguo
8422e25bb2 [debugger] add precise mode for code coverage.
Collecting precise invocation counts need to be explicitly
enabled. Once enabled, we disable optimization (optimized
code does not increment invocation count, and may inline
callees), and make sure feedback vectors interesting for
code coverage is not garbage-collected.

R=hpayer@chromium.org, jgruber@chromium.org
BUG=v8:5808

Review-Url: https://codereview.chromium.org/2686063002
Cr-Commit-Position: refs/heads/master@{#43082}
2017-02-10 08:21:03 +00:00
jbroman
c8910f3539 Clear pending message during Isolate::CancelScheduledExceptionFromTryCatch.
Without doing this, a JSMessageObject can be kept alive by the isolate, which
in turn keeps the context alive, until the message is cleared.

BUG=v8:5941

Review-Url: https://codereview.chromium.org/2675203005
Cr-Commit-Position: refs/heads/master@{#43043}
2017-02-08 16:12:59 +00:00
yangguo
c78d7fa1ae Link type feedback vectors to the shared function info.
Previously, both type feedback vector and the shared function info
of a function points to the matching type feedback metadata. This
makes finding the shared function info of a type feedback vector
difficult.

Instead, we now point the type feeback vector to the shared function
info, and find the metadata through the shared function info.

Also remove the obsolete empty type feedback vector.

R=hpayer@chromium.org, mvstanton@chromium.org
BUG=v8:5808

Review-Url: https://codereview.chromium.org/2672363002
Cr-Commit-Position: refs/heads/master@{#43026}
2017-02-08 08:33:33 +00:00
jochen
1fc5ca85fc Fix --noopt to not optimize
BUG=v8:5904,chromium:639217
R=mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2660103002
Cr-Commit-Position: refs/heads/master@{#42777}
2017-01-30 14:41:29 +00:00
petermarshall
ccf428bb04 Convert the array iterator protector to a PropertyCell.
We need it to be a PropertyCell so that we can list it as a dependency for
optimised code.

Also drive-by clean up some variable names in src/isolate-inl.h.

BUG=v8:5895

Review-Url: https://codereview.chromium.org/2658573008
Cr-Commit-Position: refs/heads/master@{#42764}
2017-01-30 09:55:21 +00:00
kozyatinskiy
cb545a8c0c [inspector] change target promise for kDebugWillHandle & kDebugDidHandle
- kDebugPromiseCreated(task, parent_task)
This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.

- kDebugEnqueueAsyncFunction(task)
This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.

- kDebugEnqueuePromiseResolve(task),
This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.

- kDebugEnqueuePromiseReject(task),
This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.

- kDebugPromiseCollected,
This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.

- kDebugWillHandle,
This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.

- kDebugDidHandle,
This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.

With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).

Before V8Debugger supported only the following:
- asyncTaskScheduled(task1)
- asyncTaskStarted(task1)
- asyncTaskFinished(task1)

Now V8Debugger supports the following:
- asyncTaskScheduled(parent_task)
..
- asyncTaskCreated(task, parent_task),
- asyncTaskStarted(task), uses parent_task scheduled stack
- asyncTaskScheduled(task)
- asyncTaskFinished(task)

Additionally: WillHandle and DidHandle were migrated to PromiseHook API.

More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE

BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2650803003
Cr-Commit-Position: refs/heads/master@{#42644}
2017-01-25 07:05:43 +00:00
jochen
0389df514d Assert that context creation doesn't throw
Instead, it is supposed to just return an empty context if it failed.
Also don't invoke interceptors (we don't for the parts that deserialize
from the snapshot anyways).

BUG=v8:5830
R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2636903002
Cr-Commit-Position: refs/heads/master@{#42404}
2017-01-17 13:01:03 +00:00
rmcilroy
5883bf2125 [Parser] Introduce AstStringConstants to share constants across AstValueFactory
Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.

BUG=v8:5203

Review-Url: https://codereview.chromium.org/2630343002
Cr-Original-Commit-Position: refs/heads/master@{#42381}
Committed: d611496b8e
Review-Url: https://codereview.chromium.org/2630343002
Cr-Commit-Position: refs/heads/master@{#42394}
2017-01-17 10:20:47 +00:00
rmcilroy
c8ac1a0ca5 Revert of [Parser] Introduce AstStringConstants to share constants across AstValueFactory (patchset #4 id:80001 of https://codereview.chromium.org/2630343002/ )
Reason for revert:
Seems to break modules-namespace2 on gcstress.

Original issue's description:
> [Parser] Introduce AstStringConstants to share constants across AstValueFactory
>
> Creates an AstStringConstants container which pre-initializes the
> string constants used by AstValueFactory. This ensures that all
> AstValueFactories will produce the same AstValue objects for constants,
> and so they can be used by the BytecodeGenerator without having to pass
> the AstValueFactory to it, enabling construction off-thread.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2630343002
> Cr-Commit-Position: refs/heads/master@{#42381}
> Committed: d611496b8e

TBR=ahaas@chromium.org,marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203

Review-Url: https://codereview.chromium.org/2638783002
Cr-Commit-Position: refs/heads/master@{#42382}
2017-01-16 16:35:15 +00:00
rmcilroy
d611496b8e [Parser] Introduce AstStringConstants to share constants across AstValueFactory
Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.

BUG=v8:5203

Review-Url: https://codereview.chromium.org/2630343002
Cr-Commit-Position: refs/heads/master@{#42381}
2017-01-16 16:06:47 +00:00
kozyatinskiy
154cb8542a [inspector] merged type and name of async task event
Inspector uses event name only for enqueue* events and doesn't really need name for other events.

BUG=v8:5738
R=jgruber@chromium.org,gsathya@chromium.org
TBR=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2628173005
Cr-Commit-Position: refs/heads/master@{#42339}
2017-01-13 19:13:40 +00:00
mstarzinger
4408f8f1d9 [runtime] Change MessageLocation::function to SFI.
This changes the {MessageLocation} structure to no longer contain a
concrete {JSFunction} object but rather a {SharedFunctionInfo}. It is
much easier by now to determine, and also the concrete closure is never
actually being used.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2628973005
Cr-Commit-Position: refs/heads/master@{#42324}
2017-01-13 12:14:56 +00:00
jgruber
b26cba7815 Ensure runtime call stats show up for microtasks
Prior to this, traces recorded through chrome://tracing would not
include time spent in RunMicrotasks.

BUG=v8:5382

Review-Url: https://codereview.chromium.org/2592793003
Cr-Commit-Position: refs/heads/master@{#42316}
2017-01-13 10:58:21 +00:00
gsathya
687b60c874 [promisehook] Pass deferred promise to Before/After callback
Before, in `var p1 = p.then(() => {}) we would trigger the
before/after callbacks with p as the associated promise, but we must
call it with p1.

Also removes promise from PromiseReactionJobInfo.

Review-Url: https://codereview.chromium.org/2633443002
Cr-Commit-Position: refs/heads/master@{#42295}
2017-01-12 22:06:55 +00:00
clemensh
df5417ae76 Refactor FrameSummary for JS and Wasm frames
Wasm frames can be either compiled or interpreted. For interpreted wasm
frames, there is only one physical stack frame representing an
arbitrary stack of interpreted functions. Hence the physical stack
frame needs to provide a summary of the underlying functions.
Summaries were tailored for JavaScript frames before. Now they are
universal.

The refactored FrameSummaries are now also used in the FrameInspector,
and from the StackFrame objects themselves, to avoid code duplication.

All dispatch is implemented "manually", making the FrameSummary still
stack-allocatable.

BUG=v8:5822
R=yangguo@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2619353006
Cr-Commit-Position: refs/heads/master@{#42279}
2017-01-12 16:54:26 +00:00
clemensh
81700ddfdc [wasm] Introduce WasmToInterpreterFrame
and rename WasmFrame to WasmCompiledFrame.
The WasmToInterpreterFrames are not used yet; this will follow in a
follow-up CL (see tracking bug for the overall picture).
Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
call from wasm code to the wasm interpreter, implemented in C++.
They will support the Summarize method to inspect the stack frames in
the wasm interpreter.

R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822

Review-Url: https://codereview.chromium.org/2623773004
Cr-Commit-Position: refs/heads/master@{#42213}
2017-01-11 10:16:10 +00:00
kozyatinskiy
754736d26c [inspector] async stacks for Promise.then calls...
... which were done after the promise has been resolved.

Goal of this CL - change promise instrumentation to support better callbacks, chained after promise resolution and prepare instrumentation for adding new asyncTaskCreated instrumentation.

Instrumentation changes:
- asyncTaskScheduled(recurring) when promise is fulfilled or rejected,
- asyncTaskCancelled when promise is collected (since [1] we can be sure that promise will survive scheduled microtasks).

Minor changes:
- async task type in inspector <-> debugger API transferred by enum instead of string,
- Debug manages async task ids based on promise objects.

More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE

[1] https://codereview.chromium.org/2581503003/

BUG=chromium:632829,v8:5738
R=dgozman@chromium.org,yangguo@chromium.org,gsathya@chromium.org

Review-Url: https://codereview.chromium.org/2578923002
Cr-Commit-Position: refs/heads/master@{#42178}
2017-01-10 12:54:12 +00:00
gsathya
a2c15ba376 [promises] Refactor debug code
-- Removes remaning debug from promise.js and moves it to c++
-- Changes debug_id to be a smi in PromiseReactionJobInfo and
   PromiseResolveThenableJobInfo.
-- Changes debug_name to be a smi in PromiseReactionJobInfo and
   PromiseResolveThenableJobInfo.
-- Adds PromiseDebugActionName and PromiseDebugActionType enums
-- Adds PromiseDebugActionNameToString and
   PromiseDebugActionTypeToString helper methods
-- Changes variable `status` to be int in runtime functions.
-- Changes debug_id to start from 1, not 0 for easier bookkeeping.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2606093002
Cr-Commit-Position: refs/heads/master@{#42052}
2017-01-03 21:43:38 +00:00
gsathya
5668ce3987 [promises] Remove deferred object
This patch stores the promise, resolve, reject properties of the
deferred object created by CreateInternalPromiseCapability and
NewPromiseCapability directly on the promise (if the promise hasn't
been fulfilled), otherwise they are stored on the
PromiseReactionJobInfo.

This patch removes the currently unused
CreateInternalPromiseCapability and inlines the call to create the
deferred promise object.

NewPromiseCapability is the only function that works with a deferred.

This patch results in a 8.5% improvement in benchmarks over 5 runs.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2590563003
Cr-Commit-Position: refs/heads/master@{#41991}
2016-12-29 20:30:28 +00:00
gsathya
a8bb874288 [isolate] remove redundant return
TBR=adamk@chromium.org

Review-Url: https://codereview.chromium.org/2604483005
Cr-Commit-Position: refs/heads/master@{#41949}
2016-12-23 19:52:43 +00:00
gsathya
0f5c69c5ed [promises] Move PromiseHasUserDefinedRejectHandler to c++
BUG=v8:5343

Review-Url: https://codereview.chromium.org/2604483002
Cr-Commit-Position: refs/heads/master@{#41947}
2016-12-23 18:03:33 +00:00
clemensh
081ac37048 [wasm] Introduce WasmSharedModuleData and refactor other objects
The new object will hold information which is shared by all clones of a
WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
future also breakpoints. From there, we can set them on each new
instantiation of any clone.

While already changing lots of the code base, I also renamed all
getters from "get_foo" to "foo", to conform to the style guide.

R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5732

Review-Url: https://codereview.chromium.org/2591653002
Cr-Commit-Position: refs/heads/master@{#41862}
2016-12-20 14:34:07 +00:00
clemensh
21a85c4a03 [wasm] Always provide a wasm instance object at runtime
When executing wasm code for testing, we did not create a
WasmInstanceObject and link it to the generated code. This required
some special handling at runtime (mainly for stack trace generation).
This CL always provides the WasmInstanceObject, such that e.g. function
names can be resolved the usual way.
The module bytes referenced by the WasmCompiledModule linked with the
WasmInstanceObject do not hold a valid wasm module yet. Instead, we
just add the bytes we need, and make the objects in WasmModule point to
those bytes (currently only used for function names). Those bytes will
not be parsed at runtime anyway.

R=titzer@chromium.org
CC=jgruber@chromium.org
BUG=v8:5620

Review-Url: https://codereview.chromium.org/2551053002
Cr-Commit-Position: refs/heads/master@{#41809}
2016-12-19 15:03:13 +00:00