1. 13 May, 2022 1 commit
  2. 18 Jan, 2022 2 commits
  3. 01 Dec, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Fix CharacterRange limits again again again · 2e17aaca
      Jakob Gruber authored
      When emitting code, character ranges must only specify ranges which
      the actual subject string (one- or two-byte) may contain.
      
      This was not always the case, specifically for ranges with
      `from <= kMaxUint8` and `to > kMaxUint8`.
      
      The reason this is so tricky: 1. not all parts of the pipeline know
      whether we are compiling for one- or two-byte subjects; 2. for
      case-insensitive regexps, an out-of-bounds CharacterRange may have an
      in-bounds case equivalent (e.g. /[Ÿ]/i also matches 'ÿ' == \u{ff}),
      which only gets added somewhere in the middle of the pipeline.
      
      Our current solution is to clamp immediately before code emission. We
      also keep the existing handling/dchecks of the 0x10ffff marker value
      which may occur in the two-byte subject case.
      
      Bug: v8:11069
      Change-Id: Ic7b34a13a900ea2aa3df032daac9236bf5682a42
      Fixed: chromium:1275096
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306569
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78186}
      2e17aaca
  4. 15 Nov, 2021 1 commit
  5. 09 Nov, 2021 1 commit
  6. 03 Nov, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Handle marker value 0x10ffff in MakeRangeArray · bfa681ff
      Jakob Gruber authored
      Unfortunately, CharacterRanges may use 0x10ffff as a marker value
      signifying 'highest possible code unit' irrespective of whether the
      regexp instance has the unicode flag or not. This value makes it
      through RegExpCharacterClass::ToNode unmodified (since no surrogate
      desugaring takes place without /u). Correctly mask out the 0xffff
      value for purposes of building our uint16_t range array.
      
      Note: It'd be better to never introduce 0x10ffff in the first place,
      but given the irregexp pipeline's lack of hackability I hesitate to
      change this - we are sure to rely on it implicitly in other spots.
      
      Drive-by: Refactors.
      
      Fixed: chromium:1264508
      Bug: v8:11069
      Change-Id: Ib3c5780e91f682f1a6d15f26eb4cf03636d93c25
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256549
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77673}
      bfa681ff
  7. 19 Oct, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Compact codegen for large character classes · 8bbb44e5
      Jakob Gruber authored
      Large character classes may easily be created when unicode
      properties (e.g.: /\p{L}/u and /\P{L}/u) are used - these are
      expanded internally into character classes that consist of hundreds
      of character ranges. Previously to this CL, we'd emit branching code
      for each of these ranges, leading to very large regexp code objects.
      
      This CL adds a new codegen mode for large character classes (where
      'large' currently means > 16 ranges). Instead of emitting branching
      code inline, the ranges are written into a ByteArray and we call into
      the C function IsCharacterInRangeArray for the actual branching logic.
      The ByteArray is smaller than emitted code and is deduplicated if the
      same character class is matched repeatedly in the same pattern.
      
      Note this mode is *not* implemented for the interpreter, since we
      currently don't have a constant pool for irregexp bytecode, and thus
      cannot reference ByteArrays.
      
      Bug: v8:11069
      Change-Id: I2d728e42d85114b796c637f791848731a104cd54
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229377Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77463}
      8bbb44e5
  8. 14 Oct, 2021 1 commit
  9. 12 Oct, 2021 1 commit
  10. 11 Oct, 2021 1 commit
  11. 19 Aug, 2021 2 commits
  12. 27 Jul, 2021 1 commit
  13. 01 Jul, 2021 1 commit
  14. 24 Jun, 2021 3 commits
  15. 18 Jun, 2021 1 commit
  16. 09 Jun, 2021 1 commit
    • Iain Ireland's avatar
      [regexp] Propagate eats_at_least for negative lookahead · 363ab5ae
      Iain Ireland authored
      In issue 11290, we disabled the propagation of EAL data out of
      lookarounds, because it was incorrect for lookahead nodes in
      loops. This caused performance regressions: for example,
      `/^\P{Letter}+$/u` (matching only characters that are not in Unicode's
      Letter category) uses negative lookahead when matching lone
      surrogates, and became about 2x slower. I spent some time looking into
      fixes, and this is what I've settled on.
      
      Some background: the implementation of lookarounds in irregexp is
      split between positive and negative lookaheads. (Lookbehinds aren't
      relevant here, because backwards matches always have EAL=0.)  Positive
      lookaheads are wrapped in BEGIN_SUBMATCH and POSITIVE_SUBMATCH_SUCCESS
      ActionNodes. BEGIN_SUBMATCH saves the current state.
      POSITIVE_SUBMATCH_SUCCESS restores the necessary state (while leaving
      any captures that occurred during the lookaround intact).
      
      Negative lookaheads also begin with a BEGIN_SUBMATCH node, but follow
      it with a NegativeLookaroundChoiceNode. This node has two successors:
      a lookaround node, and a continue node. It only executes the continue
      node if the lookaround node backtracks, which automatically restores
      the previous state. Negative lookarounds also can't update captures.
      
      This affects EAL calculations. It turns out that negative lookaheads
      are already doing the right thing: EatsAtLeastPropagator only
      propagates information from the continue node, ignoring the lookaround
      node. The same is true for quick checks (see the comment in
      RegExpLookaround:Builder::ForMatch). A BEGIN_SUBMATCH for a negative
      lookahead can simply propagate the EAL data from its successor like
      any other ActionNode, and everything works.
      
      Positive lookaheads are harder. I tried saving a pointer to the
      successor in BEGIN_SUBMATCH, but ran into problems in FillInBMInfo,
      because the EAL value corresponded to the nodes after the lookahead,
      but the analysis was still looking at the nodes inside. I fell back
      to a more modest approach: split BEGIN_SUBMATCH in two, and propagate
      EAL info for BEGIN_NEGATIVE_SUBMATCH while keeping the current
      behaviour for BEGIN_POSITIVE_SUBMATCH. This fixes the performance
      regression at hand.
      
      Two potential approaches for fixing EAL for positive lookahead are:
       1. Handling positive lookahead with its own dedicated choice node,
          like NegativeLookaroundChoiceNode.
       2. Adding an eats_at_least_inside_loop field to EatsAtLeastInfo,
          which is <= eats_at_least_from_possibly_start, and using that
          value in EatsAtLeastFromLoopEntry.
      
      Both of those approaches are more complex than I want to tackle
      right now, though.
      
      Bug: v8:11844
      Change-Id: I2a43509c2c21194b8c18f0a587fa21c194db76c2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2934858Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75031}
      363ab5ae
  17. 24 Nov, 2020 1 commit
  18. 24 Sep, 2020 1 commit
    • Jakob Gruber's avatar
      [regexp] Assign proper flags to TextNode · 5b42e3f3
      Jakob Gruber authored
      This fixes a case in which we forgot to assign flags to TextNodes
      created through
      
      AddBmpCharacters
      AddNonBmpSurrogatePairs
      AddLoneLeadSurrogates
      AddLoneTrailSurrogates
      
      functions. If these initially had a flag (e.g. case-insensitive 'i')
      set, that information was lost. This bug resulted in missing case
      folding in no_i18n builds (perhaps other things as well that just
      aren't covered by our test suite).
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Bug: v8:10131,v8:10120
      Change-Id: Icef4f0dbd47971a538e07bab2f1067c383fd59c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423718Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70106}
      5b42e3f3
  19. 10 Jul, 2020 2 commits
  20. 10 Jun, 2020 1 commit
  21. 29 Apr, 2020 1 commit
    • Jakob Gruber's avatar
      Reland "[regexp] Limit the size of inlined choice nodes" · 10842cad
      Jakob Gruber authored
      This is a reland of 6a0e7224
      
      Original change's description:
      > [regexp] Limit the size of inlined choice nodes
      >
      > Codegen for unicode property escapes (e.g.: /\p{L}/u) can produce huge
      > code objects. This effect can be further magnified through inlining,
      > leading to exponential code growth in the size of the pattern.
      >
      > This CL is a (fairly hacky) way to avoid exponential growth. We
      > recognize choice nodes with 'many' choices and disable inlining for
      > them. In the future we should fix this properly, either by using the
      > code size budget correctly, or by improving codegen for property
      > escapes.
      >
      > Bug: v8:10441
      > Change-Id: I817f145251ec8b1b9906cc735c9e9bdb004c98ed
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170229
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67433}
      
      Tbr: yangguo@chromium.org
      Bug: v8:10441
      Change-Id: I9a16cc9e8248cb46d3d16a4e2d250968cc1b7b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172679Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67462}
      10842cad
  22. 28 Apr, 2020 2 commits
    • Clemens Backes's avatar
      Revert "[regexp] Limit the size of inlined choice nodes" · f8b23009
      Clemens Backes authored
      This reverts commit 6a0e7224.
      
      Reason for revert: Fails noi18n: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/31513
      
      Original change's description:
      > [regexp] Limit the size of inlined choice nodes
      > 
      > Codegen for unicode property escapes (e.g.: /\p{L}/u) can produce huge
      > code objects. This effect can be further magnified through inlining,
      > leading to exponential code growth in the size of the pattern.
      > 
      > This CL is a (fairly hacky) way to avoid exponential growth. We
      > recognize choice nodes with 'many' choices and disable inlining for
      > them. In the future we should fix this properly, either by using the
      > code size budget correctly, or by improving codegen for property
      > escapes.
      > 
      > Bug: v8:10441
      > Change-Id: I817f145251ec8b1b9906cc735c9e9bdb004c98ed
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170229
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67433}
      
      TBR=yangguo@chromium.org,jgruber@chromium.org
      
      Change-Id: I503b8b2be539468d86e4ec1ac13074cd1c06a5cb
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10441
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169101Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67436}
      f8b23009
    • Jakob Gruber's avatar
      [regexp] Limit the size of inlined choice nodes · 6a0e7224
      Jakob Gruber authored
      Codegen for unicode property escapes (e.g.: /\p{L}/u) can produce huge
      code objects. This effect can be further magnified through inlining,
      leading to exponential code growth in the size of the pattern.
      
      This CL is a (fairly hacky) way to avoid exponential growth. We
      recognize choice nodes with 'many' choices and disable inlining for
      them. In the future we should fix this properly, either by using the
      code size budget correctly, or by improving codegen for property
      escapes.
      
      Bug: v8:10441
      Change-Id: I817f145251ec8b1b9906cc735c9e9bdb004c98ed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170229
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67433}
      6a0e7224
  23. 10 Mar, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Fix and unify non-unicode case-folding algorithms · 3fab9d05
      Iain Ireland authored
      Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a
      case-folding algorithm that doesn't quite match the Unicode
      definition. There are two places in irregexp that need to do
      case-folding. Prior to this patch, neither of them quite matched the
      spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch).
      
      This patch implements the "Canonicalize" algorithm in
      src/regexp/special-case.h, and uses it in the relevant places. It
      replaces special-case logic around upper-casing / ASCII characters
      with the following approach:
      
      1. For most characters, calling UnicodeSet::closeOver on a set
         containing that character will produce the correct set of
         case-insensitive matches.
      
      2. For a small handful of characters (like the sharp S that prompted
         this change), UnicodeSet::closeOver will include some characters
         that should be omitted. For example, although closeOver('ß') =
         "ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß'
         canonicalizes to itself, and should not match 'ẞ'. In these cases,
         we can skip the closeOver entirely, because it will never add an
         equivalent character. These characters are in the IgnoreSet.
      
      3. For an even smaller handful of characters, UnicodeSet::closeOver
         will produce some characters that should be omitted, but also some
         characters that should be included. For example, closeOver('k') =
         "kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN
         SIGN should not match either of the other two (step 3.g). To handle
         this, we put such characters in the SpecialAddSet. In these cases,
         we closeOver the original character, but filter out the results
         that do not have the same canonical value.
      
      The computation of IgnoreSet and SpecialAddSet happens at build time,
      using the pre-existing gen-regexp-special-case.cc step.
      
      R=jgruber@chromium.org
      
      Bug: v8:10248
      Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858Reviewed-by: 's avatarFrank Tang <ftang@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66641}
      3fab9d05
  24. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "[regexp] Better quick checks on loop entry nodes" · bea0ffd0
      Seth Brenith authored
      This is a reland of 4b15b984
      
      Updates since original: fix an arithmetic overflow bug, remove an invalid
      DCHECK, add a unit test that would trigger that DCHECK.
      
      Original change's description:
      > [regexp] Better quick checks on loop entry nodes
      >
      > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      > change is inspired by attempting to exit earlier from generated RegExp
      > code, when no further matches are possible because any match would be
      > too long. The motivating example this time is the following expression,
      > which tests whether a string of Unicode playing cards has five of the
      > same suit in a row:
      >
      > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      >
      > A human reading this expression can readily see that any match requires
      > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      > each repeated option reports its minimum distance to the end of a match
      > as zero. This is correct, because the LoopChoiceNode's behavior depends
      > on additional state (the loop counter). However, the preceding node, a
      > SET_REGISTER action that initializes the loop counter, could confidently
      > state that it consumes at least 10 characters. Furthermore, when we try
      > to emit a quick check for that action, we could follow only paths from
      > the LoopChoiceNode that are possible based on the minimum iteration
      > count. This change implements both of those "could"s.
      >
      > I expect this improvement to apply pretty broadly to expressions that
      > use minimum repetition counts and that don't meet the criteria for
      > unrolling. In this particular case, I get about 12% improvement on the
      > overall UniPoker test, due to reducing the execution time of this
      > expression by 85% and the execution time of another similar expression
      > that checks for n-of-a-kind by 20%.
      >
      > Bug: v8:9305
      >
      > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62963}
      
      Bug: v8:9305
      Change-Id: I992070d383009013881bf778242254c27134b650
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63009}
      bea0ffd0
  25. 30 Jul, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "[regexp] Better quick checks on loop entry nodes" · 51afbd1a
      Leszek Swirski authored
      This reverts commit 4b15b984.
      
      Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0).
      
      Original change's description:
      > [regexp] Better quick checks on loop entry nodes
      > 
      > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      > change is inspired by attempting to exit earlier from generated RegExp
      > code, when no further matches are possible because any match would be
      > too long. The motivating example this time is the following expression,
      > which tests whether a string of Unicode playing cards has five of the
      > same suit in a row:
      > 
      > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      > 
      > A human reading this expression can readily see that any match requires
      > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      > each repeated option reports its minimum distance to the end of a match
      > as zero. This is correct, because the LoopChoiceNode's behavior depends
      > on additional state (the loop counter). However, the preceding node, a
      > SET_REGISTER action that initializes the loop counter, could confidently
      > state that it consumes at least 10 characters. Furthermore, when we try
      > to emit a quick check for that action, we could follow only paths from
      > the LoopChoiceNode that are possible based on the minimum iteration
      > count. This change implements both of those "could"s.
      > 
      > I expect this improvement to apply pretty broadly to expressions that
      > use minimum repetition counts and that don't meet the criteria for
      > unrolling. In this particular case, I get about 12% improvement on the
      > overall UniPoker test, due to reducing the execution time of this
      > expression by 85% and the execution time of another similar expression
      > that checks for n-of-a-kind by 20%.
      > 
      > Bug: v8:9305
      > 
      > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62963}
      
      TBR=jgruber@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9305
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62977}
      51afbd1a
  26. 29 Jul, 2019 1 commit
    • Seth Brenith's avatar
      [regexp] Better quick checks on loop entry nodes · 4b15b984
      Seth Brenith authored
      Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      change is inspired by attempting to exit earlier from generated RegExp
      code, when no further matches are possible because any match would be
      too long. The motivating example this time is the following expression,
      which tests whether a string of Unicode playing cards has five of the
      same suit in a row:
      
      /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      
      A human reading this expression can readily see that any match requires
      at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      each repeated option reports its minimum distance to the end of a match
      as zero. This is correct, because the LoopChoiceNode's behavior depends
      on additional state (the loop counter). However, the preceding node, a
      SET_REGISTER action that initializes the loop counter, could confidently
      state that it consumes at least 10 characters. Furthermore, when we try
      to emit a quick check for that action, we could follow only paths from
      the LoopChoiceNode that are possible based on the minimum iteration
      count. This change implements both of those "could"s.
      
      I expect this improvement to apply pretty broadly to expressions that
      use minimum repetition counts and that don't meet the criteria for
      unrolling. In this particular case, I get about 12% improvement on the
      overall UniPoker test, due to reducing the execution time of this
      expression by 85% and the execution time of another similar expression
      that checks for n-of-a-kind by 20%.
      
      Bug: v8:9305
      
      Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62963}
      4b15b984
  27. 02 Jul, 2019 1 commit
  28. 01 Jul, 2019 2 commits
  29. 18 Jun, 2019 2 commits
  30. 17 Jun, 2019 2 commits
  31. 13 Jun, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[regexp] Move AST-to-Node code to a dedicated file" · d61a558a
      Jakob Gruber authored
      This is a reland of 811bfbbc
      
      Original change's description:
      > [regexp] Move AST-to-Node code to a dedicated file
      >
      > Prior to this CL, jsregexp contains a bunch of things that are slightly
      > related but would be cleaner in separate files, including: AST-to-Node
      > transformations, the compiler implementation, and a debugging printer.
      >
      > This CL extracts AST-to-Node transformations.
      >
      > Bug: v8:9359
      > Change-Id: I030cfca5c40cfd72e3a7abe2188e4654cfe2277c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655303
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62148}
      
      Tbr: yangguo@chromium.org
      Bug: v8:9359
      Change-Id: I68a16086dc56c9a059547033ca8bc1e9de1080db
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658568Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62154}
      d61a558a