Skip to content

V
V8
Switch branch/tag
  1. 24 Oct, 2018 1 commit
  3. 23 Oct, 2018 1 commit
  5. 22 Oct, 2018 2 commits
  7. 19 Oct, 2018 3 commits
  9. 16 Oct, 2018 1 commit
  11. 12 Oct, 2018 3 commits
    • Jakob Kummerow's avatar
      [refactoring] Drop roots.h -> handles.h #include · 913d363c
      Jakob Kummerow authored 
      This makes it possible for handles.h to #include objects.h, which
upcoming changes will need.

Bug: v8:3770
Change-Id: I4f500736028668749bb73fb24f9732df757e97d0
Reviewed-on: https://chromium-review.googlesource.com/c/1278487Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56615}
      913d363c
    • Clemens Hammacher's avatar
      [base] Introduce MutexGuard as typedef for LockGuard<Mutex> · 75b56661
      Clemens Hammacher authored 
      LockGuard is mostly used with Mutex. Since both are defined outside the
internal namespace, we often have to write
{base::LockGuard<base::Mutex>}. This CL shortens this to
{base::MutexGuard} across the code base

R=mlippautz@chromium.org

Bug: v8:8238
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I020d5933b73aafb98c4b72e3bb2dfd07c979ba73
Reviewed-on: https://chromium-review.googlesource.com/c/1278796Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56612}
      75b56661
    • Sathya Gunasekaran's avatar
      [Class] Fix debug scope iteration for class fields · 230dd86c
      Sathya Gunasekaran authored 
      When trying to print the scope information for the class fields
initializer function, the debugger asks the parser to parse the class
literal as a function literal (to get the scope info) ... which
doesn't quite work.

Instead of adding support for parsing the class literal, we just short
cicruit this parsing step by just returning an empty context.

This works fine because initializer function doesn't have any
variables in it's local scope.

The one caveat is that the objects in the scope above this function
(like the global) are now missing. This trade off is possibly fine
for now, as adding parsing support for class literal to only produce
would be a lot of code for not enough use.

As a follow up to this change, the devtools UI needs to be updated to
handle this empty context cleanly. Currently, it doesn't show the
`this` object if no context exists even if the `this` object is
correctly passed to the UI from the backend.

Bug: v8:5367, v8:8122
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I52965f26241bbf6abdc988783aa0fc44bb36901f
Reviewed-on: https://chromium-review.googlesource.com/c/1274268
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56611}
      230dd86c
  13. 11 Oct, 2018 1 commit
  15. 10 Oct, 2018 2 commits
    • Jakob Gruber's avatar
      [coverage] Filter out singleton ranges that alias full ranges · aac2f8c9
      Jakob Gruber authored 
      Block coverage is based on a system of ranges that can either have
both a start and end position, or only a start position (so-called
singleton ranges). When formatting coverage information, singletons
are expanded until the end of the immediate full parent range. E.g.
in:

{0, 10}  // Full range.
{5, -1}  // Singleton range.

the singleton range is expanded to {5, 10}.

Singletons are produced mostly for continuation counters that track
whether we execute past a specific language construct.

Unfortunately, continuation counters can turn up in spots that confuse
our post-processing. For example:

if (true) { ... block1 ... } else { ... block2 ... }

If block1 produces a continuation counter, it could end up with the
same start position as the else-branch counter. Since we merge
identical blocks, the else-branch could incorrectly end up with an
execution count of one.

We need to avoid merging such cases. A full range should always take
precedence over a singleton range; a singleton range should never
expand to completely fill a full range. An additional post-processing
pass ensures this.

Bug: v8:8237
Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
Reviewed-on: https://chromium-review.googlesource.com/c/1273095Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
      aac2f8c9
    • Jakob Gruber's avatar
      Revert "[coverage] change block range to avoid ambiguity." · 47d34a31
      Jakob Gruber authored 
      This reverts commit 471fef04.

Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.

Original change's description:
> [coverage] change block range to avoid ambiguity.
> 
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
> 
> R=​verwaest@chromium.org
> 
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}

TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
      47d34a31
  17. 05 Oct, 2018 1 commit
    • Peter Marshall's avatar
      [cleanup] Don't declare inline runtime functions by default · 49420760
      Peter Marshall authored 
      For each intrinsic/runtime function we define in runtime.h, an inline
version is automatically declared. We only ever use 24 of the inline
functions. Even though we don't call the other ones, macro magic means
they still take up space by existing in various arrays and tables like
kIntrinsicFunctions. They also create code in switch statements.

Some drive-by cleanups:
 - Remove the switch in NameForRuntimeId() and just use the table of
   runtime functions to lookup the name directly.
 - Remove tests for IsFunction, ClassOf and StringAdd intrinsics as
   they are the last users of the inline versions of these.
 - Remove the MaxSmi inline version as it is only used in tests.

Saves 64 KiB binary size.

Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5
Reviewed-on: https://chromium-review.googlesource.com/c/1261939
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56412}
      49420760
  19. 02 Oct, 2018 1 commit
  21. 28 Sep, 2018 3 commits
  23. 27 Sep, 2018 1 commit
    • Creddy's avatar
      Reland "[interpreter] Separate bytecodes for one-shot property loads and stores" · 0714bd9f
      Creddy authored 
      This is a reland of eccf1867

Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
> 
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
> 
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}

Bug: v8:8072
Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
Reviewed-on: https://chromium-review.googlesource.com/1245742
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56266}
      0714bd9f
  25. 26 Sep, 2018 1 commit
    • Maya Lekova's avatar
      Revert "[interpreter] Separate bytecodes for one-shot property loads and stores" · 3c3330f6
      Maya Lekova authored 
      This reverts commit eccf1867.

Reason for revert: Speculative revert because it seems to introduce a pretty stable flake on gc stress tests, see https://bugs.chromium.org/p/v8/issues/detail?id=8229

Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
> 
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
> 
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,cbruni@chromium.org,chandanreddy@google.com

Change-Id: I445db58e6d4c275b434fabad5fad775bf259033f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8072
Reviewed-on: https://chromium-review.googlesource.com/1245421Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56232}
      3c3330f6
  27. 25 Sep, 2018 1 commit
  29. 24 Sep, 2018 3 commits
  31. 21 Sep, 2018 2 commits
  33. 20 Sep, 2018 3 commits
  35. 19 Sep, 2018 2 commits
  37. 18 Sep, 2018 2 commits
  39. 17 Sep, 2018 1 commit
  41. 14 Sep, 2018 1 commit
  43. 11 Sep, 2018 2 commits
  45. 10 Sep, 2018 1 commit
  47. 06 Sep, 2018 1 commit
    • Simon Zünd's avatar
      [array] Move Array.p.unshift fall-back to Torque · cfe71156
      Simon Zünd authored 
      This CL implements a generic baseline version of Array.p.unshift
in Torque, enabling us to remove the JS fall-back.

The elements-accessor fast-path is still used, but the check whether
to use it is also moved to Torque.

Support for sparse JSArrays is removed.

Drive-by change: Small refactoring in builtins-array that will
get extended to other array builtins in a follow-up CL.

R=cbruni@chromium.org, jgruber@chromium.org

Bug: v8:7624
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7b23ce15e7b922eb333f61a408050dedec77c95a
Reviewed-on: https://chromium-review.googlesource.com/1189902
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55670}
      cfe71156