Skip to content

V
V8
Switch branch/tag
  1. 13 May, 2020 2 commits
  3. 06 May, 2020 1 commit
  5. 05 May, 2020 1 commit
  7. 16 Apr, 2020 1 commit
  9. 24 Mar, 2020 1 commit
  11. 19 Mar, 2020 1 commit
  13. 17 Mar, 2020 1 commit
  15. 06 Mar, 2020 1 commit
  17. 10 Feb, 2020 1 commit
  19. 10 Jan, 2020 2 commits
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored 
      This change moves the definitions of the bitfield flags used by Symbol
and Map to Torque. Symbol could directly follow the pattern established
by SharedFunctionInfo, but Map required some other changes:
- Until now, Torque bitfield definitions have required unsigned types. I
  thought that this would be the least-surprising behavior, since we
  never sign-extend when decoding bitfield values. However, I believe
  that the amount of churn involved in making ElementsKind be unsigned
  outweighs the benefit we were getting from this restriction (and
  similar difficulties are likely to arise in converting other bitfield
  structs to Torque), so this CL updates Torque to allow signed bitfield
  values.
- If we try to make Map extend from all of the generated classes that
  define its flags, we end up with class sizing problems because some
  compilers only apply empty base class optimization to the first in a
  row of empty base classes. We could work around this issue by
  generating macros instead of classes, but I took this as an
  opportunity for a minor clean-up instead: rather than having bitfield
  definitions for several different bitfield structs all jumbled
  together in Map, they can be split up. I think this makes the code a
  little easier to follow, but if others disagree I'm happy to implement
  macro generation instead.

Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
    • Zhao Jiazhong's avatar
      [mips] Allow concurrent patching of the jump table. · cb631803
      Zhao Jiazhong authored 
      Bug: v8:8974
Change-Id: Ib1e1c84b79190359d5ad519509b881e93d519604
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989323
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65697}
      cb631803
  21. 27 Nov, 2019 1 commit
  23. 14 Nov, 2019 2 commits
  25. 08 Nov, 2019 1 commit
  27. 07 Nov, 2019 1 commit
  29. 05 Nov, 2019 2 commits
    • Zhao Jiazhong's avatar
      [mips][builtins] Move non-JS linkage builtins code objects into RO_SPACE · c8dfd2cf
      Zhao Jiazhong authored 
      port 352bbb12 https://crrev.com/c/1893192

Original Commit Message:

  Reland "Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE"

  This is a reland of 855591a5

  Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
  Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.

  Original change's description:

  > Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
  >
  > Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
  >
  > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
  >
  > Creates an allow-list of builtins that can still go in code_space
  > including all TFJ builtins and a small manual list that should be pared
  > down in the future.
  >
  > For builtins that go in RO_SPACE a Code object is created that contains an
  > immediate trap instruction. Generally these Code objects are still no
  > smaller than CODE_SPACE Code objects because of the Code object alignment
  > requirements. This will hopefully be addressed in a follow-up CL either by
  > relaxing them or removing the instruction stream completely.
  >
  > In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
  > increases by the same amount.
  >
  > Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
  > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
  > Commit-Queue: Dan Elphick <delphick@chromium.org>
  > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
  > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
  > Cr-Commit-Position: refs/heads/master@{#64700}

Change-Id: I58c10e438f164a992041960f7a54d57be500ef48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898831
Auto-Submit: Zhao Jiazhong <kyslie3100@gmail.com>
Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64776}
      c8dfd2cf
    • Zhao Jiazhong's avatar
      [mips][builtins] Remove ParameterCount uses from InvokeFunction(Code) · 99c9e635
      Zhao Jiazhong authored 
      port 46648402 https://crrev.com/c/1871605

Original Commit Message:

CallDebugOnFunctionCall was always using Registers and not Immediates.
    Then ParameterCount is not really needed. Since updating that, we
    could update other functions, e.g InvokeFunction, to only use
    registers too.

    Also removed now irrelevant variables, e.g definitely_mismatches.

[mips][codegen] Removed ParameterCount class

port 1e696896 https://crrev.com/c/1886916

Original Commit Message:

    It was used only with Register inputs, so we can replace its uses with
    the Registers themselves.

Change-Id: I0a661519f5602bf4d52c40c6c238436b93b71664
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898826Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64753}
      99c9e635
  31. 30 Oct, 2019 1 commit
  33. 22 Oct, 2019 2 commits
    • Mu Tao's avatar
      [mips]Reland^2 "[runtime] Move Context::native_context to the map" · d8ba2856
      Mu Tao authored 
      Port 3cad6bf5

Original Commit Message:

    This is a reland of c7c47c68.

    This makes TSAN happy in addition to:

    Previously I presumed that the context read from a frame in the profiler was
    a valid context. Turns out that on non-intel we're not guaranteed that the
    frame is properly set up. In the case we looked at, the profiler took a
    sample right before writing the frame marker indicating a builtin frame,
    causing the "context" pointer from that frame to be a bytecode array. Since
    we'll read random garbage on the stack as a possible context pointer, I made
    the code reading the native context from it a little more defensive.

    Bug: v8:9860
    Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org

    Original change's description:
    > [runtime] Move Context::native_context to the map
    >
    > Remove the native context slot from contexts by making context maps
    > native-context-specific. Now we require 2 loads to go from a context to the
    > native context, but we have 1 field fewer to store when creating contexts.
    >
    > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
    > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
    > Reviewed-by: Igor Sheludko <ishell@chromium.org>
    > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
    > Reviewed-by: Maya Lekova <mslekova@chromium.org>
    > Reviewed-by: Georg Neis <neis@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#64296}

R=xwafish@gmail.com

Change-Id: I6496a8c5be8cbabf48cddc2d59111410f31eb75f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868774
Auto-Submit: Mu Tao <pamilty@gmail.com>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64486}
      d8ba2856
    • Jakob Gruber's avatar
      Remove support for builds without embedded builtins · 9362df56
      Jakob Gruber authored 
      This CL removes the V8_EMBEDDED_BUILTINS define,
FLAG_embedded_builtins, and all code for supporting
non-embedded-builtin builds.

Bug: v8:6666,v8:8519
Change-Id: I2ad7bd6614c7cd404b83d3d2bf5ff91d7b55ff2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866569
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64461}
      9362df56
  35. 26 Sep, 2019 1 commit
  37. 17 Sep, 2019 1 commit
  39. 16 Sep, 2019 1 commit
  41. 13 Sep, 2019 1 commit
  43. 11 Sep, 2019 1 commit
  45. 10 Sep, 2019 2 commits
  47. 09 Sep, 2019 1 commit
  49. 02 Sep, 2019 1 commit
    • Mu Tao's avatar
      [mips][regexp] Consolidate calls to jitted irregexp and regexp interpreter · 19b3ec76
      Mu Tao authored 
      Port 213504b9

Original Commit Message:

    The code fields in a JSRegExp object now either contain irregexp
    compiled code or a trampoline to the interpreter. This way the code
    can be executed without explicitly checking if the regexp shall be
    interpreted or executed natively.
    In case of interpreted regexp the generated bytecode is now stored in
    its own fields instead of the code fields for Latin1 and UC16
    respectively.
    The signatures of the jitted irregexp match and the regexp interpreter
    have been equalized.

Change-Id: I843b11cfdd9ecbb38f03706bcb86a5cfcbf69050
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778083
Auto-Submit: Mu Tao <pamilty@gmail.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63490}
      19b3ec76
  51. 19 Aug, 2019 1 commit
  53. 05 Aug, 2019 1 commit
  55. 01 Aug, 2019 1 commit
  57. 12 Jul, 2019 1 commit
  59. 11 Jul, 2019 1 commit
  61. 08 Jul, 2019 1 commit
  63. 17 Jun, 2019 1 commit
  65. 13 Jun, 2019 1 commit
  67. 30 May, 2019 1 commit