Skip to content

V
V8
Switch branch/tag
  1. 04 Jan, 2018 1 commit
  3. 18 Dec, 2017 1 commit
  5. 21 Nov, 2017 1 commit
  7. 07 Nov, 2017 1 commit
  9. 20 Oct, 2017 1 commit
  11. 19 Oct, 2017 1 commit
  13. 16 Oct, 2017 1 commit
  15. 13 Oct, 2017 1 commit
  17. 29 Sep, 2017 1 commit
  19. 25 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Fix (D)CHECK macros in src/{debug,inspector} · 8d38c15e
      Clemens Hammacher authored 
      Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.

This will allow us to reenable the readability/check cpplint check.

R=yangguo@chromium.org

Bug: v8:6837
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I88e5afea1ad0fdf23a81b380e64ff356bbc20112
Reviewed-on: https://chromium-review.googlesource.com/681374Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48138}
      8d38c15e
  21. 11 Sep, 2017 1 commit
  23. 05 Sep, 2017 1 commit
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · f0acede9
      Juliana Franco authored 
      This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.

No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
 
We needed to change/remove the cctests that used to check
something on this list.
 
Working in x64, ia32, arm64, arm, mips64 and mips. 
 

Bug: v8:6637
Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
TBR: mstarzinger@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/647596
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47808}
      f0acede9
  25. 04 Sep, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "Remove weak-list of optimized JS functions." · 36b50283
      Michael Achenbach authored 
      This reverts commit 84c2dfce.

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876

Original change's description:
> Remove weak-list of optimized JS functions.
> 
> This CL removes the weak-list of JS functions from the context
> and all the code that iterares over it. This list was being used
> mainly during deoptimization (for code unlinking) and during
> garbage collection. Removing it will improve performance of
> programs that create many closures and trigger many scavenge GC
> cycles.
> 
> No extra work is required during garbage collection. However,
> given that we no longer unlink code from JS functions during
> deoptimization, we leave it as it is, and on its next activation
> we check whether the mark_for_deoptimization bit of that code is
> set, and if it is, than we unlink it and jump to lazy compiled
> code. This check happens in the prologue of every code object.
> 
> We needed to change/remove the cctests that used to check
> something on this list.
> 
> Working in x64, ia32, arm64, arm, mips64 and mips. 
> 
> Bug: v8:6637
> Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
> Reviewed-on: https://chromium-review.googlesource.com/600427
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47790}

TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com

Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6637
Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47792}
      36b50283
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · 84c2dfce
      Juliana Franco authored 
      This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.

No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.

We needed to change/remove the cctests that used to check
something on this list.

Working in x64, ia32, arm64, arm, mips64 and mips. 

Bug: v8:6637
Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
Reviewed-on: https://chromium-review.googlesource.com/600427
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47790}
      84c2dfce
  27. 16 Aug, 2017 1 commit
  29. 01 Aug, 2017 1 commit
    • jgruber's avatar
      Reland "[builtins] Remove Builtins::Name() accessors" · fcaa2c2e
      jgruber authored 
      This is a reland of 2f79e035
Original change's description:
> [builtins] Remove Builtins::Name() accessors
> 
> Instead of auto-generating the Name() convenience accessor, use a macro to
> avoid wasting code space.
> 
>   BUILTIN_CODE(isolate, Name)
> 
> expands to
> 
>   isolate->builtins()->builtin_handle(Builtins::kName);
> 
> This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
> 
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
> Reviewed-on: https://chromium-review.googlesource.com/593607
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47010}

TBR=bmeurer@chromium.org,ahaas@chromium.org

Bug: v8:6624
Change-Id: I4733731e56dc8873ee06c2b36cac1918c0a658b2
Reviewed-on: https://chromium-review.googlesource.com/594087
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47037}
      fcaa2c2e
  31. 31 Jul, 2017 2 commits
    • Jakob Gruber's avatar
      Revert "[builtins] Remove Builtins::Name() accessors" · 17a26c0b
      Jakob Gruber authored 
      This reverts commit 2f79e035.

Reason for revert: Conflicts with successor CL.

Original change's description:
> [builtins] Remove Builtins::Name() accessors
> 
> Instead of auto-generating the Name() convenience accessor, use a macro to
> avoid wasting code space.
> 
>   BUILTIN_CODE(isolate, Name)
> 
> expands to
> 
>   isolate->builtins()->builtin_handle(Builtins::kName);
> 
> This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
> 
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
> Reviewed-on: https://chromium-review.googlesource.com/593607
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47010}

TBR=yangguo@chromium.org,ahaas@chromium.org,jgruber@chromium.org,bmeurer@chromium.org

Change-Id: Ia9ef5c755b26c3f4e143d87a7c51033614ea435e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/594048Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47012}
      17a26c0b
    • jgruber's avatar
      [builtins] Remove Builtins::Name() accessors · 2f79e035
      jgruber authored 
      Instead of auto-generating the Name() convenience accessor, use a macro to
avoid wasting code space.

  BUILTIN_CODE(isolate, Name)

expands to

  isolate->builtins()->builtin_handle(Builtins::kName);

This reduces the size of libv8.so by 134,752 bytes on a x64 release build.

Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
Reviewed-on: https://chromium-review.googlesource.com/593607Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47010}
      2f79e035
  33. 10 Jul, 2017 1 commit
  35. 06 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      Igor Sheludko authored 
      Properly propagate the fact that the function has a statically known name from
parser to SharedFunctionInfo objects. The empty string that has been set as
name before this CL does not help to distinguish cases like:
  var o1 = { ''(){} };
  var o1 = { [foo()](){} };
or
  var o2 = { get ''(){} };
  var o2 = { get [foo()](){} };

This is a preliminary step for using different layouts for closure objects with
and without computed names.

TBR=bmeurer@chromium.org, marja@chromium.org

Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
Reviewed-on: https://chromium-review.googlesource.com/522073
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
  37. 31 May, 2017 1 commit
    • jgruber's avatar
      [debug] Untangle DebugInfo from break point support · d3371c23
      jgruber authored 
      DebugInfo was very closely tied to break point support:
* It contained only information relevant to break points.
* It was created and freed by break point implementation.
* Existence of a DebugInfo on the shared function info implied existence of
  break points.

This CL is a step towards making DebugInfo usable by other debugging
functionality such as block coverage by decoupling it from break point support,
which is now only one kind of information stored on the DebugInfo object.

BUG=v8:6000

Review-Url: https://codereview.chromium.org/2909893002
Cr-Commit-Position: refs/heads/master@{#45640}
      d3371c23
  39. 06 Mar, 2017 1 commit
  41. 23 Feb, 2017 1 commit
  43. 16 Feb, 2017 1 commit
  45. 10 Feb, 2017 2 commits
  47. 08 Feb, 2017 1 commit
    • yangguo's avatar
      Link type feedback vectors to the shared function info. · c78d7fa1
      yangguo authored 
      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}
      c78d7fa1
  49. 07 Feb, 2017 1 commit
  51. 06 Feb, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root feedback vectors at function literal site. · aea3ce3d
      mvstanton authored 
      TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.

Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.

Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.

This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
      aea3ce3d
  53. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored 
      They have the same lifetime. It's a match!

Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.

A follow-on CL removes even more parser infrastructure related to this count.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  55. 27 Jan, 2017 1 commit
    • yangguo's avatar
      [liveedit] reimplement frame restarting. · 3f47c63d
      yangguo authored 
      Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.

We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.

R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5587

Review-Url: https://codereview.chromium.org/2636913002
Cr-Commit-Position: refs/heads/master@{#42725}
      3f47c63d
  57. 19 Jan, 2017 3 commits
  59. 12 Jan, 2017 3 commits
  61. 22 Dec, 2016 1 commit
  63. 21 Dec, 2016 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root literal arrays in function literals slots · 93df0940
      mvstanton authored 
      Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.

To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
      93df0940
  65. 15 Dec, 2016 1 commit