Skip to content

V
V8
Switch branch/tag
  1. 10 Sep, 2019 1 commit
  3. 20 Aug, 2019 1 commit
  5. 26 Jul, 2019 1 commit
  7. 08 Jul, 2019 1 commit
  9. 26 Jun, 2019 1 commit
  11. 24 May, 2019 1 commit
  13. 23 May, 2019 2 commits
  15. 22 May, 2019 1 commit
  17. 20 May, 2019 1 commit
  19. 17 May, 2019 3 commits
  21. 16 May, 2019 2 commits
  23. 10 May, 2019 1 commit
  25. 30 Apr, 2019 1 commit
  27. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored 
      Our {Vector} template provides both {start} and {begin} methods. They
return exactly the same value. Since the {begin} method is needed for
iteration, and is also what standard containers provide, this CL
switches all uses of the {start} method to use {begin} instead.

Patchset 1 was auto-generated by using this clang AST matcher:
    callExpr(
        callee(
          cxxMethodDecl(
            hasName("start"),
            ofClass(hasName("v8::internal::Vector")))
        ),
        argumentCountIs(0))

Patchset 2 was created by running clang-format. Patchset 3 then
removes the now unused {Vector::start} method.

R=jkummerow@chromium.org
TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org

Bug: v8:9183
Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  29. 03 Apr, 2019 1 commit
  31. 11 Feb, 2019 1 commit
  33. 22 Jan, 2019 1 commit
  35. 16 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Clean up base::EnumSet · 4064757c
      Clemens Hammacher authored 
      After moving to its own header, this CL cleans up some parts of the
interface. It fixes names and const-declarations of simple accessors,
and adds a named constructor to make it explicit that an EnumSet should
be constructed from an integral value.
Also refactor the use in cctest.h to have less statically declared
constants. Instead, just create the set of extensions in the individual
tests.

R=titzer@chromium.org

Bug: v8:8562
Change-Id: I6178d1aba25afa1d7f54c29ccf81505c165e7cd3
Reviewed-on: https://chromium-review.googlesource.com/c/1409366
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58862}
      4064757c
  37. 19 Dec, 2018 3 commits
  39. 22 Oct, 2018 1 commit
  41. 19 Oct, 2018 1 commit
  43. 18 Oct, 2018 1 commit
  45. 27 Jul, 2018 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Use instruction start as the key for the CodeMap · ba752ea4
      Peter Marshall authored 
      Previously we used the start address of the AbstractCode object. This
doesn't make sense for off-heap builtins, where the code isn't contained
in the object itself. It also hides other potential problems - sometimes
the sample.pc is inside the AbstractCode object header - this is
never valid.

There were a few changes necessary to make this happen:
  - Change the interface of CodeMoveEvent. Now 'to' and 'from' are both
    AbstractCode objects, which is nice because many users were taking
    'to' and adding the header offset to it to try and find the
    instruction start address. This isn't valid for off-heap builtins.
  - Fix a bug in CodeMap::MoveCode where we didn't update the CodeEntry
    object to reflect the new instruction_start.
  - Rename the 'start' field in all of the CodeEventRecord sub-classes
    to make it clear that this is the address of the first instruction.
  - Fix the confusion in RecordTickSample between 'tos' and 'pc' which
    caused pc_offset to be calculated incorrectly.

Bug: v8:7983
Change-Id: I3e9dddf74e4b2e96a5f031d216ef7008d6f184d1
Reviewed-on: https://chromium-review.googlesource.com/1148457
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54749}
      ba752ea4
  47. 23 Jul, 2018 1 commit
  49. 23 May, 2018 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Add a new profiling mode with a more detailed call tree. · ecae80cd
      Peter Marshall authored 
      The current profiling mode (called kLeafNodeLineNumbers in this CL)
produces a tree, with each node representing a stack frame that is seen
in one or more samples taken during profiling. These nodes refer to a
particular function in a stack trace, but not to a particular line or
callsite within that function.

This CL adds a new more (called kCallerLineNumbers) which produces a
different profile tree, where each stack trace seen during profiling,
including the line number, has a unique path in the tree.

The profile tree was previously keyed on CodeEntry*. Now it is keyed on
the pair of CodeEntry* and line_number, meaning it has distinct nodes
for those combinations which exist, and each distinct stack trace that
was sampled is represented in the tree.

For optimized code where we have inline frames, there are no line
numbers for the inline frames in the stack trace, causing duplicate
branches in the tree with kNoLineNumberInfo as the reported line number.
This will be addressed in follow-ups.

Bug: v8:7018
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I512e221508f5b50ec028306d212263b514a9fb24
Reviewed-on: https://chromium-review.googlesource.com/1013493
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53298}
      ecae80cd
  51. 16 May, 2018 1 commit
    • Alexei Filippov's avatar
      [cpu-profiler] Eagerly delete not used CodeEntry'es · c6c28f7a
      Alexei Filippov authored 
      Currently ProfilerListener holds all the CodeEntries it ever
created during the profiling session. It is not capable of removing
entries corresponding to the code objects discarded by GC as there's
no such code event.

However it is sometimes possible to tell if a code object was GCed.
Hook up to the CodeMap code entry removal and if the entry has never
been hit by a sample we can safely delete it.

As a bonus the CodeEntryInfo size has been reduced on x64, which also
saves 8 x <number of code entries> bytes.

BUG=v8:7719

Change-Id: I988bc5b59f3fba07157a9f472cbcf68596fcd969
Reviewed-on: https://chromium-review.googlesource.com/1054346Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53222}
      c6c28f7a
  53. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored 
      The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  55. 19 Dec, 2017 1 commit
  57. 13 Oct, 2017 1 commit
  59. 21 Sep, 2017 1 commit
  61. 29 Aug, 2017 1 commit
  63. 28 Aug, 2017 1 commit
  65. 28 Jul, 2017 1 commit
  67. 13 Jul, 2017 1 commit