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}

Reland of Ensure counters are initialized, to avoid init on non-joinable threads. (patchset #1 id:1 of https://codereview.chromium.org/2812653002/ )

Reason for revert:
Appears to be a flake. Both jgruber and I tried to repro locally and failed. Also change has little change of having had caused those failures.

Original issue's description:
> Revert of Ensure counters are initialized, to avoid init on non-joinable threads. (patchset #1 id:1 of https://codereview.chromium.org/2812543002/ )
>
> Reason for revert:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20gyp/builds/5221
>
> Original issue's description:
> > Ensure counters are initialized, to avoid init on non-joinable threads.
> >
> > This occurs in the wasm scenario described in the referenced bug.
> > DecodeWasmModule collects statistics. Blink inserts a CreateHistogramCallback that
> > can't instantiate a histogram on non-joinable threads. Turns out, DecodeWasmModule
> > is scheduled on such a thread, now that we have async compilation.
> >
> > This fix pre-initializes histograms when the callback is applied, which is assumed to
> > be in a context that can carry out the instantiation. In Blink, this happens on the main
> > thread.
> >
> > BUG=chromium:709684
> >
> > Review-Url: https://codereview.chromium.org/2812543002
> > Cr-Commit-Position: refs/heads/master@{#44522}
> > Committed: https://chromium.googlesource.com/v8/v8/+/022e7ddf232b0696eb595769fa702463c417db5e
>
> TBR=jochen@chromium.org,mtrofin@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:709684
>
> Review-Url: https://codereview.chromium.org/2812653002
> Cr-Commit-Position: refs/heads/master@{#44527}
> Committed: https://chromium.googlesource.com/v8/v8/+/038bafcb8c0435bc4130228237124331295d4713

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

Review-Url: https://codereview.chromium.org/2813673002
Cr-Commit-Position: refs/heads/master@{#44529}

Revert of Ensure counters are initialized, to avoid init on non-joinable threads. (patchset #1 id:1 of https://codereview.chromium.org/2812543002/ )

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20gyp/builds/5221

Original issue's description:
> Ensure counters are initialized, to avoid init on non-joinable threads.
>
> This occurs in the wasm scenario described in the referenced bug.
> DecodeWasmModule collects statistics. Blink inserts a CreateHistogramCallback that
> can't instantiate a histogram on non-joinable threads. Turns out, DecodeWasmModule
> is scheduled on such a thread, now that we have async compilation.
>
> This fix pre-initializes histograms when the callback is applied, which is assumed to
> be in a context that can carry out the instantiation. In Blink, this happens on the main
> thread.
>
> BUG=chromium:709684
>
> Review-Url: https://codereview.chromium.org/2812543002
> Cr-Commit-Position: refs/heads/master@{#44522}
> Committed: https://chromium.googlesource.com/v8/v8/+/022e7ddf232b0696eb595769fa702463c417db5e

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

Review-Url: https://codereview.chromium.org/2812653002
Cr-Commit-Position: refs/heads/master@{#44527}

This occurs in the wasm scenario described in the referenced bug.
DecodeWasmModule collects statistics. Blink inserts a CreateHistogramCallback that
can't instantiate a histogram on non-joinable threads. Turns out, DecodeWasmModule
is scheduled on such a thread, now that we have async compilation.

This fix pre-initializes histograms when the callback is applied, which is assumed to
be in a context that can carry out the instantiation. In Blink, this happens on the main
thread.

BUG=chromium:709684

Review-Url: https://codereview.chromium.org/2812543002
Cr-Commit-Position: refs/heads/master@{#44522}

... by avoiding reads through timer objects allocated on stack of another thread and
explicitly maintaining current RuntimeCallCounter object in RuntimeCallStats instead.

Change-Id: I54eaf078dc1e77dc47ded963903d54ffb583f377
Reviewed-on: https://chromium-review.googlesource.com/471667Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44491}

Move builtin definitions (i.e. BUILTIN_LIST and family) to a separate header
in preparation for auto-generation of TFS interface descriptors.

BUG=v8:6116

Review-Url: https://codereview.chromium.org/2784793002
Cr-Commit-Position: refs/heads/master@{#44221}

This saves 72 KiB (approximately 0.1%) of the Chrome APK size of for ARM/Android.

In Counters, each similar group of counters generates a compact data structure,
which a loop then iterates over, rather than having the full loop unrolled
(though the compiler will automatically unroll small ones).

In RuntimeCallStats, the compiler was not being clever enough to avoid
initializing count_ and time_ to zero individually, even after the initialization
of names was moved into a loop. As a result, RuntimeCallCounter was modified
to have a non-initializing constructor for exclusive use by RuntimeCallStats,
which explicitly initializes the counters in a loop. Since v8::base::TimeDelta
does not support an uninitialized state, time_ was changed to be stored as
int64_t microseconds internally, which generates the same code (it's the same
representation as TimeDelta).

BUG=v8:6119

Review-Url: https://codereview.chromium.org/2759033002
Cr-Commit-Position: refs/heads/master@{#43996}

JavaScript cannot represent integer larger than 2^53 - 1 from JSON, thus this
patch removes AppendLongInteger and convert long integer to string using
std::to_string.

TBR=cbruni@chromium.org

Review-Url: https://codereview.chromium.org/2557463003
Cr-Commit-Position: refs/heads/master@{#41533}

BUG=chromium:665398

Review-Url: https://codereview.chromium.org/2549653002
Cr-Commit-Position: refs/heads/master@{#41462}

RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.

BUG=

Review-Url: https://codereview.chromium.org/2511093002
Cr-Commit-Position: refs/heads/master@{#41254}

Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #15 id:320001 of https://codereview.chromium.org/2511093002/ )

Reason for revert:
The test is very flaky on the bots, e.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/17031
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14776

Original issue's description:
> [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
>
> RuntimeTimerScopes always subtract their own time from the parent timer's
> counter to properly account for the own time. Once a scope is destructed it
> adds it own timer to the current active counter. However, if the current
> counter is changed with CorrectCurrentCounterId we will attribute all the
> subtimers to the previous counter, and add the own time to the new counter.
> This way it is possible to end up with negative times in certain counters but
> the overall would still be correct.
>
> BUG=
>
> Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
> Committed: https://crrev.com/491651792d7818aed04eaeffb9890b5a309b543e
> Cr-Original-Commit-Position: refs/heads/master@{#41142}
> Cr-Commit-Position: refs/heads/master@{#41214}

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

Review-Url: https://codereview.chromium.org/2526843002
Cr-Commit-Position: refs/heads/master@{#41229}

RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.

BUG=

Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
Review-Url: https://codereview.chromium.org/2511093002
Cr-Original-Commit-Position: refs/heads/master@{#41142}
Cr-Commit-Position: refs/heads/master@{#41214}

Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #10 id:180001 of https://codereview.chromium.org/2511093002/ )

Reason for revert:
Wronged it even more.

Original issue's description:
> [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
>
> RuntimeTimerScopes always subtract their own time from the parent timer's
> counter to properly account for the own time. Once a scope is destructed it
> adds it own timer to the current active counter. However, if the current
> counter is changed with CorrectCurrentCounterId we will attribute all the
> subtimers to the previous counter, and add the own time to the new counter.
> This way it is possible to end up with negative times in certain counters but
> the overall would still be correct.
>
> BUG=
>
> Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
> Cr-Commit-Position: refs/heads/master@{#41142}

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

Review-Url: https://codereview.chromium.org/2519073002
Cr-Commit-Position: refs/heads/master@{#41150}

RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.

BUG=

Review-Url: https://codereview.chromium.org/2511093002
Cr-Commit-Position: refs/heads/master@{#41142}

The timer can be missing in the timers stack when RCS is started dynamically.

BUG=chromium:665659
TBR=cbruni@chromium.org

Review-Url: https://codereview.chromium.org/2505813002
Cr-Commit-Position: refs/heads/master@{#41049}

BUG=

Review-Url: https://codereview.chromium.org/2490643002
Cr-Commit-Position: refs/heads/master@{#41001}

In tracing we collect runtime statistics data based on top level trace events,
in this patch we force to clear the whole runtime statistics stack when we
enter top level trace events.

Review-Url: https://codereview.chromium.org/2483583002
Cr-Commit-Position: refs/heads/master@{#40867}

Review-Url: https://codereview.chromium.org/2484963002
Cr-Commit-Position: refs/heads/master@{#40847}

This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.

BUG=v8:5590

Review-Url: https://codereview.chromium.org/2460973003
Cr-Commit-Position: refs/heads/master@{#40745}

Revert of [Tracing] Use TracingCategoryObserver in runtime statistics (patchset #6 id:140001 of https://codereview.chromium.org/2460973003/ )

Reason for revert:
Static-Initializers failed on Ubuntu-12.04

Original issue's description:
> [Tracing] Use TracingCategoryObserver in runtime statistics
>
> This patch is a follow-up patch to enable runtime statistics to use
> TracingCategoryObserver.
>
> BUG=v8:5590

TBR=cbruni@chromium.org,fmeawad@chromium.org,alph@chromium.org,bmeurer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5590

Review-Url: https://codereview.chromium.org/2469403005
Cr-Commit-Position: refs/heads/master@{#40743}

This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.

BUG=v8:5590

Review-Url: https://codereview.chromium.org/2460973003
Cr-Commit-Position: refs/heads/master@{#40742}

Make RuntimeCallTimer::parent_ and RuntimeCallStats::current_timer_
fields atomic as they are accessed from the signal handler.

BUG=chromium:660428

Review-Url: https://codereview.chromium.org/2464973002
Cr-Commit-Position: refs/heads/master@{#40709}

Previously we reset runtime counters and dump them when we enter, exit top level
trace events respectively. However, there is gap between two top level trace
events and runtime counters may be activated, resetting the counters makes the
accumulated time inaccurate, and we may end up with negative time due to the
nature of how we accumulate time.

This patch fixes this problem by only resetting counters when there's no
counters active, and before dump counters, we traverse current active counters
to calculate their time, and then restart their timer.

BUG=chromium:658145

Review-Url: https://codereview.chromium.org/2457523002
Cr-Commit-Position: refs/heads/master@{#40653}

We introduced TracedValue into V8 tracing previously, this patch uses it to
build JSON string of runtime statistics instead of using stringstream as buffer.

BUG=v8:5089
LOG=N

Review-Url: https://chromiumcodereview.appspot.com/2418303002
Cr-Commit-Position: refs/heads/master@{#40443}

BUG=chromium:645378

Review-Url: https://codereview.chromium.org/2422143002
Cr-Commit-Position: refs/heads/master@{#40355}

Previously we didn't implement TRACE_STR_COPY when we write trace events to
file, which causes us to allocate a growing independent memory chunk for dumped
runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
this memory allocation can be avoided, this patch removes it.

BUG=v8:5089

Committed: https://crrev.com/e1997bb7d780d12e3a89078e8dd652dcf1d90039
Review-Url: https://codereview.chromium.org/2342643004
Cr-Original-Commit-Position: refs/heads/master@{#39462}
Cr-Commit-Position: refs/heads/master@{#39510}

Revert of [Tracing] Remove unnecessary memory allocation in runtime call stats. (patchset #1 id:1 of https://codereview.chromium.org/2342643004/ )

Reason for revert:
Revert because this breaks V8's roll into Chromium. ASAN complains about memory accesses in a particular unit test.

Borked roll CL:
https://codereview.chromium.org/2348833002/

Reproduce breakage with:

1, args.gn:
  v8_deprecation_warnings = true
  use_goma = true
  is_asan = true
2, ninja -C out/... content_browsertests
3, out/.../content_browsertests --gtest_filter=V8SamplingProfilerTest.*

Original issue's description:
> [Tracing] Remove unnecessary memory allocation in runtime call stats.
>
> Previously we didn't implement TRACE_STR_COPY when we write trace events to
> file, which causes us to allocate a growing independent memory chunk for dumped
> runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
> this memory allocation can be avoided, this patch removes it.
>
> BUG=v8:5089
>
> Committed: https://crrev.com/e1997bb7d780d12e3a89078e8dd652dcf1d90039
> Cr-Commit-Position: refs/heads/master@{#39462}

TBR=cbruni@chromium.org,fmeawad@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5089

Review-Url: https://codereview.chromium.org/2349593004
Cr-Commit-Position: refs/heads/master@{#39475}

Previously we didn't implement TRACE_STR_COPY when we write trace events to
file, which causes us to allocate a growing independent memory chunk for dumped
runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
this memory allocation can be avoided, this patch removes it.

BUG=v8:5089

Review-Url: https://codereview.chromium.org/2342643004
Cr-Commit-Position: refs/heads/master@{#39462}

https://codereview.chromium.org/2296243002/ introduced 2 minor bugs
related to the Reset scope.

The tracing version requires that we reset the counters everytime we
start a new top level trace event, unless the top level one is not
really a top level (i.e. has the right type but called in a nested way)

Bugs are:
1- Reseting was guarded behind a check for the runtime call stats
version only.
2- We never set that we are already inside a scope, so the nested
case would fail as well.

R=lpy@chromium.org, cbruni@chromium.org
BUG=642373

Review-Url: https://codereview.chromium.org/2311033002
Cr-Commit-Position: refs/heads/master@{#39214}

After we landed the tracing runtime call stats, which gave
us a lot of V8 insight in tracing, we noticed that there is
some arising issues and discrepancies.

Issues include:
Missing trace events, that happened due to
transforming those trace events into runtime calls

Discrepancies include:
Missing categories in Runtime call stats like GC,
because we are not handling the Scoped runtime calls
properly in the tracing version.

To reduce/eliminate those issue, we are taking a small
step back. We are unifying the RuntimeStats code and
using the original one. That would allow us to use all
the original probes but emit trace events from them.
We are also putting back the trace-events in their place.

The output from both system should be intact (Except of
the addition of the missing trace-events).

Also as a byproduct, we are reducing the number of context
scopes by half since we are using the same scope as
runtime call stats.

As a follow up to this CL, we will address the non-scoped
Runtime Call Stats (mainly in GC).
BUG=642373

Review-Url: https://codereview.chromium.org/2296243002
Cr-Commit-Position: refs/heads/master@{#39180}

Currently we have V8 RuntimeCallStats that is independently from tracing when
running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
stats into tracing, by having a global table of runtime call counters each
isolate, resetting the table each time we enter a top level trace event, and
dumping the table for each top level trace event. This will make trace file more
compat, as well as enable runtime call stats in tracing system.

This patch adds ~5% overhead to V8 when the category is enabled, we measure the
overhead by running a script when category is enabled.

BUG=v8:5089

Committed: https://crrev.com/d014866173eaa2b548c566217b2c94b1d49385fa
Committed: https://crrev.com/1ca3b73bba4a7253ca8eeef39321d70e7d414331
Committed: https://crrev.com/3f936a5b17754783e92d2146eaf66c88a78ee45b
Review-Url: https://codereview.chromium.org/2187693002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#38270}
Cr-Original-Original-Commit-Position: refs/heads/master@{#38314}
Cr-Original-Commit-Position: refs/heads/master@{#38403}
Cr-Commit-Position: refs/heads/master@{#38510}

Revert of [Tracing] Embed V8 runtime call stats into tracing. (patchset #8 id:140001 of https://codereview.chromium.org/2187693002/ )

Reason for revert:
Leaks block chromium roll:
https://codereview.chromium.org/2219083003/

Example build:
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_asan_rel_ng/builds/205435

You can add the trybot from tryserver.chromium.linux, linux_chromium_asan_rel_ng, on reland.

Original issue's description:
> [Reland][Tracing] Embed V8 runtime call stats into tracing.
>
> Currently we have V8 RuntimeCallStats that is independently from tracing when
> running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
> stats into tracing, by having a global table of runtime call counters each
> isolate, resetting the table each time we enter a top level trace event, and
> dumping the table for each top level trace event. This will make trace file more
> compat, as well as enable runtime call stats in tracing system.
>
> This patch adds ~5% overhead to V8 when the category is enabled, we measure the
> overhead by running a script when category is enabled.
>
> BUG=v8:5089
>
> Committed: https://crrev.com/d014866173eaa2b548c566217b2c94b1d49385fa
> Committed: https://crrev.com/1ca3b73bba4a7253ca8eeef39321d70e7d414331
> Committed: https://crrev.com/3f936a5b17754783e92d2146eaf66c88a78ee45b
> Cr-Original-Original-Commit-Position: refs/heads/master@{#38270}
> Cr-Original-Commit-Position: refs/heads/master@{#38314}
> Cr-Commit-Position: refs/heads/master@{#38403}

TBR=cbruni@chromium.org,fmeawad@chromium.org,bmeurer@chromium.org,adamk@chromium.org,rmcilroy@chromium.org,lpy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5089
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2221853002
Cr-Commit-Position: refs/heads/master@{#38412}

Currently we have V8 RuntimeCallStats that is independently from tracing when
running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
stats into tracing, by having a global table of runtime call counters each
isolate, resetting the table each time we enter a top level trace event, and
dumping the table for each top level trace event. This will make trace file more
compat, as well as enable runtime call stats in tracing system.

This patch adds ~5% overhead to V8 when the category is enabled, we measure the
overhead by running a script when category is enabled.

BUG=v8:5089

Committed: https://crrev.com/d014866173eaa2b548c566217b2c94b1d49385fa
Committed: https://crrev.com/1ca3b73bba4a7253ca8eeef39321d70e7d414331
Review-Url: https://codereview.chromium.org/2187693002
Cr-Original-Original-Commit-Position: refs/heads/master@{#38270}
Cr-Original-Commit-Position: refs/heads/master@{#38314}
Cr-Commit-Position: refs/heads/master@{#38403}

Revert of [Tracing] Embed V8 runtime call stats into tracing. (patchset #8 id:140001 of https://codereview.chromium.org/2187693002/ )

Reason for revert:
Mac64 ASAN failure. https://build.chromium.org/p/client.v8/builders/V8%20Mac64%20ASAN/builds/7810/steps/Check/logs/Threading4

Original issue's description:
> [Reland][Tracing] Embed V8 runtime call stats into tracing.
>
> Currently we have V8 RuntimeCallStats that is independently from tracing when
> running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
> stats into tracing, by having a global table of runtime call counters each
> isolate, resetting the table each time we enter a top level trace event, and
> dumping the table for each top level trace event. This will make trace file more
> compat, as well as enable runtime call stats in tracing system.
>
> This patch adds ~5% overhead to V8 when the category is enabled, we measure the
> overhead by running a script when category is enabled.
>
> BUG=v8:5089
>
> Committed: https://crrev.com/d014866173eaa2b548c566217b2c94b1d49385fa
> Committed: https://crrev.com/1ca3b73bba4a7253ca8eeef39321d70e7d414331
> Cr-Original-Commit-Position: refs/heads/master@{#38270}
> Cr-Commit-Position: refs/heads/master@{#38314}

TBR=cbruni@chromium.org,fmeawad@chromium.org,machenbach@chromium.org,bmeurer@chromium.org,adamk@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5089

Review-Url: https://codereview.chromium.org/2200373003
Cr-Commit-Position: refs/heads/master@{#38315}

Currently we have V8 RuntimeCallStats that is independently from tracing when
running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
stats into tracing, by having a global table of runtime call counters each
isolate, resetting the table each time we enter a top level trace event, and
dumping the table for each top level trace event. This will make trace file more
compat, as well as enable runtime call stats in tracing system.

This patch adds ~5% overhead to V8 when the category is enabled, we measure the
overhead by running a script when category is enabled.

BUG=v8:5089

Committed: https://crrev.com/d014866173eaa2b548c566217b2c94b1d49385fa
Review-Url: https://codereview.chromium.org/2187693002
Cr-Original-Commit-Position: refs/heads/master@{#38270}
Cr-Commit-Position: refs/heads/master@{#38314}

Revert of [Tracing] Embed V8 runtime call stats into tracing. (patchset #6 id:100001 of https://codereview.chromium.org/2187693002/ )

Reason for revert:
Sanitizer failures:

https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/10989/
https://build.chromium.org/p/client.v8/builders/V8%20Mac64%20ASAN/builds/7786/

Original issue's description:
> [Tracing] Embed V8 runtime call stats into tracing.
>
> Currently we have V8 RuntimeCallStats that is independently from tracing when
> running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
> stats into tracing, by having a global table of runtime call counters each
> isolate, resetting the table each time we enter a top level trace event, and
> dumping the table for each top level trace event. This will make trace file more
> compat, as well as enable runtime call stats in tracing system.
>
> This patch adds ~5% overhead to V8 when the category is enabled, we measure the
> overhead by running a script when category is enabled.
>
> BUG=v8:5089
>
> Committed: https://crrev.com/d014866173eaa2b548c566217b2c94b1d49385fa
> Cr-Commit-Position: refs/heads/master@{#38270}

TBR=cbruni@chromium.org,fmeawad@chromium.org,machenbach@chromium.org,bmeurer@chromium.org,adamk@chromium.org,rmcilroy@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5089

Review-Url: https://codereview.chromium.org/2203913004
Cr-Commit-Position: refs/heads/master@{#38275}

Currently we have V8 RuntimeCallStats that is independently from tracing when
running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
stats into tracing, by having a global table of runtime call counters each
isolate, resetting the table each time we enter a top level trace event, and
dumping the table for each top level trace event. This will make trace file more
compat, as well as enable runtime call stats in tracing system.

This patch adds ~5% overhead to V8 when the category is enabled, we measure the
overhead by running a script when category is enabled.

BUG=5089

Review-Url: https://codereview.chromium.org/2187693002
Cr-Commit-Position: refs/heads/master@{#38270}

RuntimeCallStats::Print invokes this function many times. The uses of
STL all get inlined as a result, causing the Print() function to take up
156KB of binary size. Out-of-lining this method reduces the size to
under 18KB!

BUG=v8:5240

Review-Url: https://codereview.chromium.org/2188953003
Cr-Commit-Position: refs/heads/master@{#38182}

Now builtins are sorted by use, not implementation.

R=bmeurer@chromium.org
BUG=v8:5197

Review-Url: https://codereview.chromium.org/2145413002
Cr-Commit-Position: refs/heads/master@{#37761}

Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.

Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.

BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg

Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}