Skip to content

V
V8
Switch branch/tag
  1. 30 May, 2019 1 commit
  3. 23 May, 2019 1 commit
  5. 22 May, 2019 1 commit
  7. 21 May, 2019 1 commit
  9. 10 May, 2019 1 commit
  11. 11 Apr, 2019 1 commit
  13. 10 Apr, 2019 3 commits
  15. 08 Apr, 2019 2 commits
  17. 03 Apr, 2019 1 commit
  19. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored 
      Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.

Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  21. 12 Mar, 2019 1 commit
  23. 21 Feb, 2019 3 commits
  25. 08 Feb, 2019 1 commit
  27. 28 Jan, 2019 1 commit
  29. 27 Dec, 2018 1 commit
  31. 19 Dec, 2018 1 commit
  33. 17 Dec, 2018 2 commits
  35. 06 Dec, 2018 1 commit
  37. 16 Nov, 2018 1 commit
    • Mythri's avatar
      Update bytecode handlers to work without feedback vectors · a6cb4903
      Mythri authored 
      This is the first in a series of patches for adding support to execute
without feedback vectors. This cl updates some of the bytecode handlers
to check for feedback before using them. All these bytecodes only collect
type feedback, so their funcitonality would not change. This cl changes the
implementation for following bytecode:
  BinaryOperation
  CompareOperation
  UnaryOperation
  Call

Bug: v8:8394
Change-Id: I284bf9c010718c65f3fe76b6f3f4461b5bfa6742
Reviewed-on: https://chromium-review.googlesource.com/c/1333667
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57580}
      a6cb4903
  39. 29 Oct, 2018 1 commit
  41. 09 Oct, 2018 1 commit
  43. 08 Oct, 2018 1 commit
  45. 20 Sep, 2018 1 commit
  47. 31 Aug, 2018 1 commit
  49. 07 Aug, 2018 1 commit
  51. 20 Jun, 2018 1 commit
  53. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored 
      Currently each isolate stores its own array of
{CallInterfaceDescriptorData}. This array has size 173, and each entry
has 40 bytes. That's already 7kB per isolate.
Additionally, each {CallInterfaceDescriptorData} allocates two
heap-allocated arrays, which probably add up to more than the static
size of the {CallInterfaceDescriptorData}. Note that all the
{CallInterfaceDescriptorData} instances are initialized eagerly on
isolate creation.

Since {CallInterfaceDescriptor} is totally isolate independent itself,
this CL refactors the current design to avoid a copy of them per
isolate, and instead shares them process-wide. Still, we need to free
the allocated heap arrays when the last isolate dies to avoid leaks.
This can probably be refactored later by statically initializing more
and avoiding the heap allocations all together.

This refactoring will also allow us to use {CallInterfaceDescriptor}s
from wasm background compilation threads, which are not bound to any
isolate.

R=mstarzinger@chromium.org, titzer@chromium.org

Bug: v8:6600
Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
Reviewed-on: https://chromium-review.googlesource.com/1100879
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
  55. 07 Jun, 2018 1 commit
  57. 24 May, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [generators] Store parameters in the generator object. · ea7499f5
      Jaroslav Sevcik authored 
      Currently, we context allocate all parameters for generators.

With this CL, we keep arguments on stack (unless they escape to inner
closure) and copy them between the stack and the generator's register
file on suspend/resume. This will save context allocation in most cases.

Note: There is an asymmetry between suspend and resume.
- Suspend copies arguments and registers to the generator.
- Resume copies only the registers from the generator, the arguments
  are copied by the ResumeGenerator trampoline.

Bug: v8:5164
Change-Id: I6333898c60abf461b1ab1b5c6d3dc7188fa95649
Reviewed-on: https://chromium-review.googlesource.com/1063712
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53327}
      ea7499f5
  59. 23 May, 2018 2 commits
  61. 18 May, 2018 1 commit
  63. 17 May, 2018 1 commit
  65. 09 May, 2018 1 commit