Skip to content

V
V8
Switch branch/tag
  1. 21 Mar, 2017 1 commit
    • jbroman's avatar
      Generate less code in v8::internal::Counters constructor · 53562fd9
      jbroman authored 
      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}
      53562fd9
  3. 06 Dec, 2016 1 commit
  5. 02 Dec, 2016 1 commit
  7. 24 Nov, 2016 1 commit
    • cbruni's avatar
      [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters · 244dd002
      cbruni authored 
      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}
      244dd002
  9. 23 Nov, 2016 2 commits
  11. 21 Nov, 2016 2 commits
    • cbruni's avatar
      Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically... · 10a31136
      cbruni authored 
      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}
      10a31136
    • cbruni's avatar
      [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters · f6c74d96
      cbruni authored 
      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}
      f6c74d96
  13. 16 Nov, 2016 1 commit
  15. 15 Nov, 2016 1 commit
  17. 09 Nov, 2016 1 commit
  19. 08 Nov, 2016 1 commit
  21. 04 Nov, 2016 1 commit
  23. 03 Nov, 2016 2 commits
  25. 02 Nov, 2016 1 commit
  27. 28 Oct, 2016 1 commit
    • lpy's avatar
      [Tracing] Fix inaccurate timer calculation in runtime statistics. · 92d9a56a
      lpy authored 
      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}
      92d9a56a
  29. 19 Oct, 2016 1 commit
  31. 17 Oct, 2016 1 commit
  33. 19 Sep, 2016 1 commit
  35. 16 Sep, 2016 2 commits
    • vogelheim's avatar
      Revert of [Tracing] Remove unnecessary memory allocation in runtime call... · eb7ba290
      vogelheim authored 
      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}
      eb7ba290
    • lpy's avatar
      [Tracing] Remove unnecessary memory allocation in runtime call stats. · e1997bb7
      lpy authored 
      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}
      e1997bb7
  37. 06 Sep, 2016 1 commit
    • fmeawad's avatar
      [RuntimeCallStats] Fix reset scope for tracing · 5dd94008
      fmeawad authored 
      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}
      5dd94008
  39. 05 Sep, 2016 1 commit
    • fmeawad's avatar
      [RuntimeCallStats] Move tracing runtime instrumentation closer to the original version. · e5ba156d
      fmeawad authored 
      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}
      e5ba156d
  41. 10 Aug, 2016 1 commit
  43. 08 Aug, 2016 1 commit
  45. 05 Aug, 2016 1 commit
  47. 03 Aug, 2016 4 commits
  49. 29 Jul, 2016 1 commit
  51. 14 Jul, 2016 1 commit
  53. 30 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] New frame type for exits to C++ builtins · 5febc27b
      jgruber authored 
      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}
      5febc27b
  55. 29 Jun, 2016 2 commits
  57. 17 Jun, 2016 1 commit
  59. 13 Jun, 2016 1 commit
    • jkummerow's avatar
      [--runtime-call-stats] Fix ACCESSOR handler computation · 31ca317a
      jkummerow authored 
      When running with FLAG_runtime_call_stats, native accessor accesses must
go through the runtime for accurate accounting. Previously the slow_stub()
was used as a handler in order to accomplish this, but it could never be
looked up from the code cache successfully due to mismatched code flags,
which could cause more handler recompilations than in normal operation.
This patch fixes that by emitting a runtime call into the compiled
handler instead of using the slow_stub().

Drive-by cleanup: drop the unused StoreIC_Megamorphic builtin.

Review-Url: https://codereview.chromium.org/2054133002
Cr-Commit-Position: refs/heads/master@{#36926}
      31ca317a
  61. 10 Jun, 2016 1 commit
  63. 30 May, 2016 1 commit