1. 28 Apr, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Handlify RegExpCompileData::code · 6bb3f0c0
      Iain Ireland authored
      RegExpMacroAssembler::GetCode returns a Handle<Object>. However, that
      Handle is almost immediately dereferenced, and is stored as a bare
      Object in both RegExpCompiler::CompilationResult and RegExpCompileData.
      
      This makes SpiderMonkey's rooting hazard analysis somewhat
      antsy. While RegExpCompileData is alive on the stack, the hazard
      analysis will not allow any calls that might GC, because it isn't
      smart enough to prove that the code field can't be clobbered by a GC.
      
      As far as I can tell, there is no real hazard here, but storing a
      Handle in RegExpCompileData instead of a bare Object will simplify SM
      and prevent a future patch from accidentally breaking something.
      
      Bug: v8:10406
      Change-Id: I9642dd05c591bfd23b340a89df2f2bf5c9fcac2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161578Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67441}
      6bb3f0c0
  2. 19 Mar, 2020 3 commits
    • Iain Ireland's avatar
      Reland "[regexp] Rewrite error handling" · 560f2d8b
      Iain Ireland authored
      This is a reland of e80ca24c
      
      Original change's description:
      > [regexp] Rewrite error handling
      >
      > This patch modifies irregexp's error handling. Instead of representing
      > errors as C strings, they are represented as an enumeration value
      > (RegExpError), and only converted to strings when throwing the error
      > object in regexp.cc. This makes it significantly easier to integrate
      > into SpiderMonkey. A few notes:
      >
      > 1. Depending on whether the stack overflows during parsing or
      >    analysis, the stack overflow message can vary ("Stack overflow" or
      >    "Maximum call stack size exceeded"). I kept that behaviour in this
      >    patch, under the assumption that stack overflow messages are
      >    (sadly) the sorts of things that real world code ends up depending
      >    on.
      >
      > 2. Depending on the point in code where the error was identified,
      >    invalid unicode escapes could be reported as "Invalid Unicode
      >    escape", "Invalid unicode escape", or "Invalid Unicode escape
      >    sequence". I fervently hope that nobody depends on the specific
      >    wording of a syntax error, so I standardized on the first one. (It
      >    was both the most common, and the most consistent with other
      >    "Invalid X escape" messages.)
      >
      > 3. In addition to changing the representation, this patch also adds an
      >    error_pos field to RegExpParser and RegExpCompileData, which stores
      >    the position at which an error occurred. This is used by
      >    SpiderMonkey to provide more helpful messages about where a syntax
      >    error occurred in large regular expressions.
      >
      > 4. This model is closer to V8's existing MessageTemplate
      >    infrastructure. I considered trying to integrate it more closely
      >    with MessageTemplate, but since one of our stated goals for this
      >    project was to make it easier to use irregexp outside of V8, I
      >    decided to hold off.
      >
      > R=jgruber@chromium.org
      >
      > Bug: v8:10303
      > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66784}
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66798}
      560f2d8b
    • Leszek Swirski's avatar
      Revert "[regexp] Rewrite error handling" · 2193f691
      Leszek Swirski authored
      This reverts commit e80ca24c.
      
      Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)
      
      Original change's description:
      > [regexp] Rewrite error handling
      > 
      > This patch modifies irregexp's error handling. Instead of representing
      > errors as C strings, they are represented as an enumeration value
      > (RegExpError), and only converted to strings when throwing the error
      > object in regexp.cc. This makes it significantly easier to integrate
      > into SpiderMonkey. A few notes:
      > 
      > 1. Depending on whether the stack overflows during parsing or
      >    analysis, the stack overflow message can vary ("Stack overflow" or
      >    "Maximum call stack size exceeded"). I kept that behaviour in this
      >    patch, under the assumption that stack overflow messages are
      >    (sadly) the sorts of things that real world code ends up depending
      >    on.
      > 
      > 2. Depending on the point in code where the error was identified,
      >    invalid unicode escapes could be reported as "Invalid Unicode
      >    escape", "Invalid unicode escape", or "Invalid Unicode escape
      >    sequence". I fervently hope that nobody depends on the specific
      >    wording of a syntax error, so I standardized on the first one. (It
      >    was both the most common, and the most consistent with other
      >    "Invalid X escape" messages.)
      > 
      > 3. In addition to changing the representation, this patch also adds an
      >    error_pos field to RegExpParser and RegExpCompileData, which stores
      >    the position at which an error occurred. This is used by
      >    SpiderMonkey to provide more helpful messages about where a syntax
      >    error occurred in large regular expressions.
      > 
      > 4. This model is closer to V8's existing MessageTemplate
      >    infrastructure. I considered trying to integrate it more closely
      >    with MessageTemplate, but since one of our stated goals for this
      >    project was to make it easier to use irregexp outside of V8, I
      >    decided to hold off.
      > 
      > R=​jgruber@chromium.org
      > 
      > Bug: v8:10303
      > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66784}
      
      TBR=jgruber@chromium.org,iireland@mozilla.com
      
      Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10303
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66786}
      2193f691
    • Iain Ireland's avatar
      [regexp] Rewrite error handling · e80ca24c
      Iain Ireland authored
      This patch modifies irregexp's error handling. Instead of representing
      errors as C strings, they are represented as an enumeration value
      (RegExpError), and only converted to strings when throwing the error
      object in regexp.cc. This makes it significantly easier to integrate
      into SpiderMonkey. A few notes:
      
      1. Depending on whether the stack overflows during parsing or
         analysis, the stack overflow message can vary ("Stack overflow" or
         "Maximum call stack size exceeded"). I kept that behaviour in this
         patch, under the assumption that stack overflow messages are
         (sadly) the sorts of things that real world code ends up depending
         on.
      
      2. Depending on the point in code where the error was identified,
         invalid unicode escapes could be reported as "Invalid Unicode
         escape", "Invalid unicode escape", or "Invalid Unicode escape
         sequence". I fervently hope that nobody depends on the specific
         wording of a syntax error, so I standardized on the first one. (It
         was both the most common, and the most consistent with other
         "Invalid X escape" messages.)
      
      3. In addition to changing the representation, this patch also adds an
         error_pos field to RegExpParser and RegExpCompileData, which stores
         the position at which an error occurred. This is used by
         SpiderMonkey to provide more helpful messages about where a syntax
         error occurred in large regular expressions.
      
      4. This model is closer to V8's existing MessageTemplate
         infrastructure. I considered trying to integrate it more closely
         with MessageTemplate, but since one of our stated goals for this
         project was to make it easier to use irregexp outside of V8, I
         decided to hold off.
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66784}
      e80ca24c
  3. 21 Oct, 2019 2 commits
    • Jakob Gruber's avatar
      [regexp] Apply the backtrack limit in jitted code · 0089006f
      Jakob Gruber authored
      .. similar to how it is applied in the interpreter. We reserve a stack
      slot for the backtrack count, increment it on each backtrack, and fail
      if the limit is hit.
      
      Bug: v8:9695
      Change-Id: I835888c612d6c8bfa2f34e73ab8c8241dcabc6ed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864938Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64426}
      0089006f
    • Jakob Gruber's avatar
      [regexp] Add a backtracking limit in the interpreter · 48756fcf
      Jakob Gruber authored
      V8 uses a backtracking regexp engine, which has the caveat that some
      regexp patterns can have exponential runtime behavior when excessive
      backtracking is involved.
      
      Especially when regexp patterns are user-controlled, it would be useful
      to be able to set an upper limit for a single regexp execution. This CL
      takes an initial step in that direction by adding a backtracking limit
      (intended to approximate execution time):
      
      - The limit is stored in the JSRegExp's data array.
      - A limit can currently only be set through the %NewRegExpWithLimit
      runtime function.
      - The limit is applied during interpreter execution. When exceeded, the
      interpreter stops execution and returns FAILURE (even if continued
      execution would at some later point have resulted in SUCCESS).
      
      In follow-up CLs, this mechanism will be extended to work in jitted
      regexp code, and exposed through the V8 API.
      
      Bug: v8:9695
      Change-Id: Iadb5c100052f4a63b26f1ec49cf97c6713a66b9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864934
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64417}
      48756fcf
  4. 09 Sep, 2019 1 commit
  5. 29 Aug, 2019 1 commit
  6. 12 Aug, 2019 1 commit
  7. 24 Jul, 2019 1 commit
  8. 19 Jul, 2019 1 commit
    • Sathya Gunasekaran's avatar
      Revert "Reland "[regexp] Call the regexp interpreter without CEntry overhead"" · aa478cac
      Sathya Gunasekaran authored
      This reverts commit c2ee4a79.
      
      Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9)
      See https://bugs.chromium.org/p/chromium/issues/detail?id=985624
      
      Original change's description:
      > Reland "[regexp] Call the regexp interpreter without CEntry overhead"
      >
      > This is a reland of d4d28b73
      >
      > Original change's description:
      > > [regexp] Call the regexp interpreter without CEntry overhead
      > >
      > > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
      > >
      > > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
      > >
      > > Bug: v8:8954
      > > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
      > > Commit-Queue: Patrick Thier <pthier@google.com>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#62753}
      >
      > Bug: v8:8954
      > Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@google.com>
      > Cr-Commit-Position: refs/heads/master@{#62794}
      
      TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8954, chromium:985624
      Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62824}
      aa478cac
  9. 18 Jul, 2019 1 commit
    • Patrick Thier's avatar
      Reland "[regexp] Call the regexp interpreter without CEntry overhead" · c2ee4a79
      Patrick Thier authored
      This is a reland of d4d28b73
      
      Original change's description:
      > [regexp] Call the regexp interpreter without CEntry overhead
      > 
      > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
      > 
      > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
      > 
      > Bug: v8:8954
      > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
      > Commit-Queue: Patrick Thier <pthier@google.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62753}
      
      Bug: v8:8954
      Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Patrick Thier <pthier@google.com>
      Cr-Commit-Position: refs/heads/master@{#62794}
      c2ee4a79
  10. 17 Jul, 2019 2 commits
  11. 18 Jun, 2019 2 commits
  12. 17 Jun, 2019 2 commits
  13. 13 Jun, 2019 3 commits
  14. 23 May, 2019 1 commit
  15. 22 May, 2019 1 commit
  16. 09 Apr, 2019 1 commit
  17. 03 Apr, 2019 1 commit
  18. 02 Apr, 2019 1 commit
  19. 26 Feb, 2019 1 commit
  20. 23 Jan, 2019 1 commit
  21. 26 Dec, 2018 1 commit
  22. 27 Nov, 2018 1 commit
  23. 25 Nov, 2018 1 commit
  24. 24 Nov, 2018 1 commit
  25. 12 Nov, 2018 1 commit
  26. 29 Oct, 2018 1 commit
  27. 19 Oct, 2018 1 commit
  28. 18 Sep, 2018 2 commits
  29. 04 Jul, 2018 1 commit
  30. 22 Jun, 2018 1 commit
  31. 01 Jun, 2018 1 commit