Skip to content

V
V8
Switch branch/tag
  1. 05 May, 2021 1 commit
    • Daniel Dromboski's avatar
      [tools] More Python 3 compatibility fixes · 8807f0ad
      Daniel Dromboski authored 
      These should all be forward/backward compatible with Python 2/Python 3.

[tools] Tweak statusfile.py for Python 3

.iteritems() does not exist in Python 3, only .items().

(While .iteritems() was meant to be an optimization over .items()
in Python 2, .items() should work fine, and it is forward/backward
compatible.)


[tools] Fix another Python 3 issue in mb.py

sys.platform used to return e.g. 'linux2', which is 'linux' plus
whatever the first digit of `uname -r` was when Python was built.
As of Python 3.3, it always returns just 'linux' for Linux OSes.
Use `sys.platform.startswith('linux')` for forward/backward
compatibility.


[tools] Make base_runner.py Python 3 compatible

dict.keys() returns a dict_keys in Python 3, whereas it
used to return a simple array. list() is forward/backward
compatible with identical results on Python 2/3 (returns array).

(Tested on Linux x64, trying to recreate NodeJS's CI workflow.)


[tools] Make tools/dev/v8gen.py work with Python 3

dict.keys() returns a dict_keys in Python 3, whereas it
used to return a simple array. list() is forward/backward
compatible with identical results on Python 2/3 (returns array).

Comparing a None-type value numerically used to result in the
None-type value always being considered "less than" the thing
it is compared to. As of Python 3, numerically comparing against
None or None-typed values results in an error. Check if a value
is truthy before numerically comparing it, for forward/backward
compatibility.

print() used to transparently decode byte strings in Python 2.
In Python 3, they must be explicitly decoded first.

(Tested on Linux 64-bit, trying to recreate NodeJS's CI workflow.)

Bug: v8:9871
Change-Id: I059bf98577a67649bbe7ec49848989d468da96b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867270Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74369}
      8807f0ad
  3. 03 May, 2021 2 commits
  5. 29 Apr, 2021 1 commit
  7. 26 Apr, 2021 2 commits
  9. 23 Apr, 2021 1 commit
  11. 22 Apr, 2021 1 commit
  13. 21 Apr, 2021 1 commit
  15. 14 Apr, 2021 1 commit
  17. 12 Apr, 2021 1 commit
  19. 01 Apr, 2021 2 commits
  21. 22 Mar, 2021 1 commit
  23. 19 Mar, 2021 2 commits
  25. 17 Mar, 2021 1 commit
  27. 26 Feb, 2021 1 commit
  29. 23 Feb, 2021 1 commit
  31. 22 Feb, 2021 1 commit
    • Clemens Backes's avatar
      [no-wasm] Skip wasm tests if wasm is disabled · 18136654
      Clemens Backes authored 
      This CL introduces a test runner flag to detect if webassembly has been
disabled. Since all tests that require wasm are alrady skipped in
lite mode, we introduce a has_webassembly flag for the test runner which
checks for v8_enable_webassembly=true and v8_enable_lite_mode=false.
As a drive-by, we also do not set the V8_ENABLE_WEBASSEMBLY
preprocessor flag if lite mode is enabled.

The status files are updated by splitting wasm tests from the
"lite_mode" section and checking for "not has_webassembly" instead.

Note that the v8_enable_webassembly=false configuration is not tested
on any bot currently, but I will make sure that all tests keep passing
on further changes in this configuration.

R=machenbach@chromium.org

Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I1841eb1f1633cb47e0c079f4a4a4d769ca3a9cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710425Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72898}
      18136654
  33. 16 Feb, 2021 1 commit
  35. 12 Feb, 2021 5 commits
  37. 10 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Directly read PropertyCells" · 87df0b7e
      Georg Neis authored 
      This reverts commit 42cd9eb7.

Reason for revert: Clusterfuzz issues, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=1176318

Original change's description:
> [compiler] Directly read PropertyCells
>
> Main changes:
>
> - Introduce a new broker data kind kBackgroundSerialized for objects
>   that can be serialized in the background (when direct reads are on).
>   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
>   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> - Make PropertyCell use that new kind.
> - Introduce a bottleneck in runtime code for changes to PropertyCells
>   and make sure that a certain protocol is followed that allows
>   concurrent reads from the background thread.
> - Improve interface of PropertyCell in various ways.
>
> Bug: v8:7790
> Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72586}

TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org

Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72619}
      87df0b7e
  39. 09 Feb, 2021 2 commits
  41. 01 Feb, 2021 1 commit
  43. 29 Jan, 2021 1 commit
  45. 28 Jan, 2021 1 commit
  47. 22 Jan, 2021 1 commit
  49. 08 Jan, 2021 1 commit
  51. 05 Jan, 2021 1 commit
    • Andreas Haas's avatar
      [wasm] Remove negative implication from --single-threaded to --liftoff · 3345472f
      Andreas Haas authored 
      The negative implication from --single-threaded to --liftoff was
introduced because with --single-threaded, no tier-up to TurboFan is
possible, and TurboFan provides faster code and smaller code

This CL removes this implication. The reason is that this implication
does not only define the default compiler for --single-threaded to
TurboFan, and also completely disables the option to use Liftoff
instead. By removing the implication, and embedder who uses
--single-threaded can decide by themselves if they want to use Liftoff
by setting --liftoff, or if they don't want to use Liftoff by setting
--no-liftoff.

R=clemensb@chromium.org

Bug: v8:11279
Change-Id: Ie6e64a42823b87484135364ecb4589cfd188db5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599548Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71917}
      3345472f
  53. 16 Dec, 2020 1 commit
  55. 25 Nov, 2020 1 commit
    • Mythri A's avatar
      [turboprop] Don't use concurrent inlining for TurboFan compilations · 7f15f3e7
      Mythri A authored 
      With concurrent inlining, the inlining phase happens on the background
thread and the data needed for the inlining phase is serialized on
the main thread. The serialization phase tries to gather data about
functions called which is sometimes more expensive than inlining phase
itself. So it's better not to use concurrent inlining for TurboFan
compilations when tiering up from Turboprop to TurboFan. Turboprop
compilations don't inline and hence it is OK to continue using
concurrent inlining for Turboprop compilations.

Bug: v8:9684
Change-Id: Ib529905213fa7f0df84ee52218adc27f7c219f60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557504
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71405}
      7f15f3e7
  57. 19 Nov, 2020 1 commit
  59. 18 Nov, 2020 1 commit
  61. 16 Nov, 2020 1 commit