Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 07 Feb, 2017 1 commit
  5. 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
  7. 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
  9. 19 Jan, 2017 3 commits
  11. 12 Jan, 2017 3 commits
  13. 22 Dec, 2016 1 commit
  15. 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
  17. 15 Dec, 2016 1 commit
  19. 14 Dec, 2016 1 commit
  21. 08 Dec, 2016 1 commit
  23. 21 Nov, 2016 1 commit
  25. 17 Oct, 2016 1 commit
  27. 05 Oct, 2016 2 commits
  29. 12 Sep, 2016 1 commit
  31. 16 Aug, 2016 1 commit
  33. 29 Jul, 2016 1 commit
  35. 28 Jul, 2016 2 commits
  37. 27 Jul, 2016 1 commit
  39. 26 Jul, 2016 1 commit
  41. 25 Jul, 2016 1 commit
  43. 14 Jul, 2016 1 commit
  45. 13 Jul, 2016 1 commit
    • mlippautz's avatar
      [heap] Rework and improve object stats tracing · 2b2a1694
      mlippautz authored 
      - Instead of tracing during marking we can now trace in a separate phase in MC.
  (Heap is iterable.)
- Add more subtypes for fixed arrays, reducing the unknown bucket to around ~8%
  (local run).
- Refactor collection calls to have a single bottleneck.
- Provide JSON-based output format that can be "easily" processed in JS.

BUG=
R=ulan@chromium.org,hpayer@chromium.org

Review-Url: https://codereview.chromium.org/2129173002
Cr-Commit-Position: refs/heads/master@{#37718}
      2b2a1694
  47. 02 Jun, 2016 2 commits
    • jkummerow's avatar
      Refactor Maps' code_cache · 31882103
      jkummerow authored 
      Most maps have a small code cache (often only one entry), so this patch
optimizes memory consumption of such cases by using plain FixedArrays,
only switching to CodeCacheHashTables when the number of cached entries
gets so large that linear-scan lookups get too slow.

On loading inbox.google.com, this gets the aggregate size of all maps'
code caches (there are about 13,600 of them) from 4300 KB to 970 KB.

Review-Url: https://codereview.chromium.org/2021373002
Cr-Commit-Position: refs/heads/master@{#36681}
      31882103
    • mythria's avatar
      Updates incremental marking pass to collect object statistics. · 31392d70
      mythria authored 
      Object statistics were collected during the mark compact phase. If
an incremental marking happened before mark compact phase then most
of the objects are already visited and hence this phase does not collect
accurate statistics. This cl updates incremental marking pass to collect
object statistics along with mark compact phase.

BUG=

Review-Url: https://codereview.chromium.org/1943423002
Cr-Commit-Position: refs/heads/master@{#36678}
      31392d70
  49. 06 Apr, 2016 1 commit
    • verwaest's avatar
      Use a dictionary-mode code cache on the map rather than a dual system. · d2eb555e
      verwaest authored 
      The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.

This CL additionally deletes some dead IC code.

BUG=

Review URL: https://codereview.chromium.org/1846963002

Cr-Commit-Position: refs/heads/master@{#35291}
      d2eb555e
  51. 03 Dec, 2015 1 commit
  53. 30 Nov, 2015 2 commits
  55. 02 Sep, 2015 2 commits