1. 19 Feb, 2020 1 commit
  2. 18 Feb, 2020 2 commits
  3. 12 Feb, 2020 1 commit
  4. 07 Feb, 2020 2 commits
    • Ulan Degenbaev's avatar
      [heap] Enable --huge_max_old_generation_size by default and add tests · 1d54a600
      Ulan Degenbaev authored
      Now ResourceConstraints::ConfigureDefaults sets the heap limit to 4GB
      if the physical memory size is greater or equal to 16GB on 64-bit
      platforms.
      
      This CL also adds tests for configuring heap limits from the physical
      memory size.
      
      Bug: chromium:1045034
      Change-Id: If0d5a237b2db31309a9a2a6456d950ef70dc71af
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043833
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66174}
      1d54a600
    • Mythri A's avatar
      Disable one shot optimizations · e85ffb46
      Mythri A authored
      We used to optimize functions that are expected to executed only
      once by not allocating feedback slots for some of the bytecodes. This
      would help in reducing the memory and avoiding initializing feedback
      that would be never used. With lazy feedback allocation, we don't
      allocate feedback vectors for most of such functions anyway.
      
      The generated bytecode for oneshot optimized functions is different and
      if we don't properly track this information we might end up generating
      different bytecode for the same function. This could causes problems
      when there is a mismatch between the feedback slots used by the new
      bytecode and the old bytecode. Since we potentially get most of the
      benefits of this optimization with lazy feedback vector allocation
      we can simplify the code by disabling this optimization.
      
      Bug: chromium:1045824
      Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66172}
      e85ffb46
  5. 06 Feb, 2020 1 commit
    • Steve Blackburn's avatar
      Serialization without heap assumptions. · 1d2c043a
      Steve Blackburn authored
      Currently back references to regular objects are encoded in terms of
      a relative address, index by chunk index and chunk offset.   This
      approach has the advantage of avoiding the need for a table of
      back-references at deserialization time, but makes strong assumptions
      about the way objects are organized in memory (for example, this will
      not work if the allocator uses a free list rather than a bump pointer).
      
      I did some quick measurements and found that the absolute number of
      objects and back-references is low, suggesting that simply indexing
      objects would work with little (or no) observable impact on peak
      memory use during deserialization.   Indexing only back referenced
      objects is not implemented in this simple CL, but could fairly easily
      be added.
      
      Given that the existing mechanism will remain in place, I have
      implemented the object index by simply making chunk size one, so
      every object lives on its own chunk (with offset zero).   This is
      the moral equivalent to indexing each object but is a more minimal
      change.  Directly encoding an object index will be more efficient,
      the trade off made here is just to keep the change absolutely minimal.
      
      If using an object index becomes the default, this can be optimized
      first by only using an index for each object that is actually back-
      referenced (about half of all objects in my measurements), and more
      aggressively, a technique like register allocation could be used at
      serialization time to limit the number of indices to the maximum
      number of outstanding back-references at any time (basically a live-
      range analysis of back-references).
      
      Bug: v8:9533
      Change-Id: I1b7ae87e954f67f6405c2bbdf3b4a4f385af8579
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030742
      Commit-Queue: Steve Blackburn <steveblackburn@google.com>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66154}
      1d2c043a
  6. 31 Jan, 2020 2 commits
  7. 29 Jan, 2020 1 commit
  8. 27 Jan, 2020 1 commit
  9. 24 Jan, 2020 1 commit
  10. 22 Jan, 2020 3 commits
  11. 21 Jan, 2020 1 commit
  12. 17 Jan, 2020 1 commit
  13. 16 Jan, 2020 1 commit
  14. 14 Jan, 2020 2 commits
  15. 13 Jan, 2020 1 commit
    • Pierre Langlois's avatar
      [arm64][builtins] Allow simulator instructions in builtins. · d0650ae1
      Pierre Langlois authored
      Simulator-specific instructions are very useful, we can:
      
        - Place breakpoints that enable the simulator's interactive debugger, allowing
          us to see registers, the stack and print JS objects.
      
        - Enable and disable simulator tracing dynamically.
      
        - Call printf() directly, as the simulator cannot easily support its calling
          convention.
      
      However these tools are not available when generating builtins. The reason is
      that when cross-compiling, builtins are generated for real hardware but may
      still run inside the simulator on the host if we have a custom snapshot. Using
      the `v8_embed_script` GN option will do that for example but embedders may also
      do this with the V8 API.
      
      mksnapshot cannot tell the difference between generating code for a simulator
      build and a cross-build. If we change this, we can allow us to use
      simulator-specific features in builtins in simulator builds.
      
      So in this patch we:
      
        - Introduce a --target_is_simulator mksnapshot flag to drive the
          enable_simulator_code Assembler option.
      
        - Make sure the assembler respect the option instead of the USE_SIMULATOR
          macro.
      
      
      Change-Id: I7a7249f514427c1a2518a1af3679679596a72c7e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991497Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#65734}
      d0650ae1
  16. 10 Jan, 2020 2 commits
    • Clemens Backes's avatar
      Remove --perf-prof flag on non-linux · 25f242ad
      Clemens Backes authored
      The fuzzers picked up this flag, and are now complaining that they run
      into UNREACHABLE/FATAL too often because the {PerfJitLogger} is not
      implemented on non-linux platforms.
      This CL removes the flag if it's not supported, so users get a warning
      about the unknown flag, but otherwise it's ignored. This should unblock
      the fuzzers, and slightly reduces binary size on non-linux.
      
      R=ahaas@chromium.org
      
      Bug: chromium:1035233
      Change-Id: I6b9282318bc82ff23173bc83ae31cb2d8cbdcdb7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993969
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65695}
      25f242ad
    • Jakob Kummerow's avatar
      [test][wasm] Allow testing of huge memories · cfc4bba0
      Jakob Kummerow authored
      This patch maintains the previous default value of the flag controlling
      the max size of Wasm memories, but allows the limit to be raised on the
      command line.
      Bonus content: improve the multi-mapped mock allocator by falling back
      to regular allocation for small requests.
      More bonus content: make debug-mode Wasm tests faster.
      
      Bug: v8:6306
      Change-Id: Idabae5734794b06e65d45b3a6165dbd488847f3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981157
      Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65681}
      cfc4bba0
  17. 09 Jan, 2020 1 commit
    • Ulan Degenbaev's avatar
      [heap] Implement per-context marking worklist draining · e27e6fd6
      Ulan Degenbaev authored
      This changes the marking worklist draining for the main thread
      marker and the concurrent marker to use the following algorithm in
      per-context mode:
      1) Pop an object from the marking worklist.
      2) Try to infer the native context that owns the objects.
         This is done using a new NativeContextInferrer class.
      3) If the inference is successful, then change the active marking
         worklist to the worklist of the inferred native context.
      4) Otherwise, keep the current active marking worklist.
      5) Visit the object. Newly discovered objects will be pushed
         onto the active marking worklist.
      6) Account the object size for the native context corresponding
         to the active marking worklist.
         This is done using a new NativeContextStats class.
      
      The main property of the algorithm is that each object for which
      we couldn't infer the native context is either attributed to
      the native context retaining it or is not attributed to any native
      context.
      
      Bug: chromium:973627
      
      Change-Id: Ide4ab992275d115279f971d89ace657f4c05e176
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981491
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65663}
      e27e6fd6
  18. 08 Jan, 2020 3 commits
  19. 07 Jan, 2020 1 commit
  20. 27 Dec, 2019 1 commit
  21. 20 Dec, 2019 2 commits
  22. 19 Dec, 2019 1 commit
  23. 18 Dec, 2019 1 commit
  24. 17 Dec, 2019 3 commits
    • Maya Lekova's avatar
      [turbofan] Add a nesting limit for the child serializer · b297fcc5
      Maya Lekova authored
      Add a --max-serializer-nesting flag which defaults to 25.
      
      Fixed: chromium:1034768
      Change-Id: Ib68f26ce4bf53db297b25d16a046d275beaec642
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969895
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65486}
      b297fcc5
    • Zhang, Shiyu's avatar
      Reland "Support Intel VTune ITT API" · 0b812b72
      Zhang, Shiyu authored
      This is a reland of 5f5b4b04
      
      Original change's description:
      > Support Intel VTune ITT API
      > 
      > Add VTune domain support extension to use VTune Domain/Task API and
      > tagging trace data for particular JS code block.
      > 
      > How to use:
      > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
      > file to download intel/ittapi by 'gclient sync'
      > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
      > 3. Run d8 with flag '--enable-vtune-domain-support'
      > 
      > The Vtune Domain/Task API can be invoked from JS to mark JS code block.
      > You can mark the start of a JS task by
      >     vtunedomainmark(domain_name, task_name, "start")
      > and the end of a task by
      >     vtunedomainmark(domain_name, task_name, "end")
      > Tasks can nest.
      > 
      > The VTune API (ittapi) is integrated as an external third party library
      > while the v8_vtune_jit also relies on the VTune ittapi. We have another
      > patch almost ready which refactors the v8_vtune_jit related code to
      > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
      > code after this patch stabilized and landed.
      > 
      > 
      > Contributed by fanchen.kong@intel.com
      > 
      > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
      > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65409}
      
      Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65478}
      0b812b72
    • Dominik Inführ's avatar
      [objects] Add extension field to JSArrayBuffer · 221f4068
      Dominik Inführ authored
      Add pointer-sized field extension to the JSArrayBuffer class. Only
      reserve space for this field when feature is enabled for now.
      
      Bug: v8:10064
      Change-Id: Idb6fdcdce2a048e6aed9a892bc46ce029e1119f3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1956166Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65471}
      221f4068
  25. 13 Dec, 2019 1 commit
  26. 11 Dec, 2019 3 commits
    • Joshua Litt's avatar
      Revert "Reland "[replaceAll] Stage String.prototype.replaceAll."" · 38b4b671
      Joshua Litt authored
      This reverts commit 7e632f57.
      
      Reason for revert: clusterfuzzed
      Bug: chromium:1032906
      
      Original change's description:
      > Reland "[replaceAll] Stage String.prototype.replaceAll."
      > 
      > This reverts commit 3114000a.
      > 
      > Reason for revert: Clusterfuzz issue should be fixed.
      > 
      > Original change's description:
      > > Revert "[replaceAll] Stage String.prototype.replaceAll."
      > > 
      > > This reverts commit 825f65d3.
      > > 
      > > Reason for revert: Clusterfuzzed
      > > Bug: chromium:1028475
      > > 
      > > Original change's description:
      > > > [replaceAll] Stage String.prototype.replaceAll.
      > > > 
      > > > Intent to ship thread:
      > > > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/raep1X9R_SE
      > > > 
      > > > Bug: v8:9801
      > > > Change-Id: I61c559b82b4119084420ffb0a14a27774e37c760
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930608
      > > > Reviewed-by: Adam Klein <adamk@chromium.org>
      > > > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#65161}
      > > 
      > > TBR=adamk@chromium.org,joshualitt@chromium.org
      > > 
      > > Change-Id: I7fa44eda475b8f421f74491e60a3131d381eb789
      > > No-Presubmit: true
      > > No-Tree-Checks: true
      > > No-Try: true
      > > Bug: v8:9801
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1935024
      > > Reviewed-by: Joshua Litt <joshualitt@chromium.org>
      > > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#65175}
      > 
      > TBR=adamk@chromium.org,joshualitt@chromium.org
      > 
      > # Not skipping CQ checks because original CL landed > 1 day ago.
      > 
      > Bug: chromium:1028475, v8:9801
      > Change-Id: Idb5fbd1ec38084222357aeb2d9ff05d703f10eb5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1946737
      > Reviewed-by: Joshua Litt <joshualitt@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65308}
      
      TBR=adamk@chromium.org,joshualitt@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1028475, v8:9801
      Change-Id: I17dd634cac7b11d4db8d24ec30be10c06dea757b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1961941Reviewed-by: 's avatarJoshua Litt <joshualitt@chromium.org>
      Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65414}
      38b4b671
    • Maya Lekova's avatar
      Revert "Support Intel VTune ITT API" · d8053c9a
      Maya Lekova authored
      This reverts commit 5f5b4b04.
      
      Reason for revert: Breaks vtunejit bot - see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20vtunejit/32958
      
      Original change's description:
      > Support Intel VTune ITT API
      > 
      > Add VTune domain support extension to use VTune Domain/Task API and
      > tagging trace data for particular JS code block.
      > 
      > How to use:
      > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
      > file to download intel/ittapi by 'gclient sync'
      > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
      > 3. Run d8 with flag '--enable-vtune-domain-support'
      > 
      > The Vtune Domain/Task API can be invoked from JS to mark JS code block.
      > You can mark the start of a JS task by
      >     vtunedomainmark(domain_name, task_name, "start")
      > and the end of a task by
      >     vtunedomainmark(domain_name, task_name, "end")
      > Tasks can nest.
      > 
      > The VTune API (ittapi) is integrated as an external third party library
      > while the v8_vtune_jit also relies on the VTune ittapi. We have another
      > patch almost ready which refactors the v8_vtune_jit related code to
      > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
      > code after this patch stabilized and landed.
      > 
      > 
      > Contributed by fanchen.kong@intel.com
      > 
      > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
      > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65409}
      
      TBR=machenbach@chromium.org,hpayer@chromium.org,verwaest@chromium.org,shiyu.zhang@intel.com
      
      Change-Id: I44a6e5b1aa32e753ae41966ed321ed787cc752f8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960291Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65410}
      d8053c9a
    • Zhang, Shiyu's avatar
      Support Intel VTune ITT API · 5f5b4b04
      Zhang, Shiyu authored
      Add VTune domain support extension to use VTune Domain/Task API and
      tagging trace data for particular JS code block.
      
      How to use:
      1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
      file to download intel/ittapi by 'gclient sync'
      2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
      3. Run d8 with flag '--enable-vtune-domain-support'
      
      The Vtune Domain/Task API can be invoked from JS to mark JS code block.
      You can mark the start of a JS task by
          vtunedomainmark(domain_name, task_name, "start")
      and the end of a task by
          vtunedomainmark(domain_name, task_name, "end")
      Tasks can nest.
      
      The VTune API (ittapi) is integrated as an external third party library
      while the v8_vtune_jit also relies on the VTune ittapi. We have another
      patch almost ready which refactors the v8_vtune_jit related code to
      depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
      code after this patch stabilized and landed.
      
      
      Contributed by fanchen.kong@intel.com
      
      Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
      Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65409}
      5f5b4b04