1. 06 Sep, 2022 1 commit
  2. 13 May, 2022 1 commit
  3. 29 Sep, 2021 1 commit
  4. 23 Sep, 2021 1 commit
  5. 19 Aug, 2021 2 commits
  6. 18 Aug, 2021 2 commits
  7. 18 Jun, 2021 1 commit
  8. 17 Jun, 2021 1 commit
  9. 11 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Don't update last match info in @@split special case · 51fcfd58
      Jakob Gruber authored
      V8 implements a fast-path for RegExp.prototype.split which diverges
      from the spec: instead of creating a new sticky regexp instance
      `splitter` and running it in a loop, we reuse the existing non-sticky
      regexp without looping through each character.
      
      This works fine in most cases, but we run into issues when matching at
      the very end of the string. According to the spec, matches at the end
      of the string are impossible in @@split, but in our fast-path
      implementation they can happen.
      
      The obvious fix would be to remove our fast-path but this comes with
      high performance costs. The fix implemented in this CL adds a special
      flag to `exec` s.t. matches at the end of the string can be treated as
      failures. This is only relevant for @@split.
      
      Bug: chromium:1075514
      Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72644}
      51fcfd58
  10. 12 Jan, 2021 1 commit
    • Camillo Bruni's avatar
      [tools] Add DisableGCMole scope · d16a2a68
      Camillo Bruni authored
      Make sure gcmole detects issue in DisallowGarbageCollection scopes.
      
      DisallowGarbageCollection is widely used in the codebase to document
      code that doesn't allocate. However, this has the rather unexpected
      side-effect that gcmole is not run when such a scope is active.
      
      This CL changes the default behavior of gcmole to run even with
      DisallowGarbageCollection scopes present. This will give us the best
      results of both worlds, dynamic checks by the fuzzer, and static
      analysis by gcmole.
      
      To allow crazy local raw pointer operations there is a new
      DisableGCMole scope that explicitly disables gcmole.
      
      Change-Id: I0a78fb3b4ceaad35be9bcf7293d917a41f90c91f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615419Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72039}
      d16a2a68
  11. 20 Nov, 2020 1 commit
  12. 30 Oct, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Add 'l' flag to force experimental engine · 5720d205
      Martin Bidlingmaier authored
      This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l)
      that forces execution in linear time.  These regexps are handled by the
      experimental engine.  If the experimental engine cannot handle the
      pattern, an exception is thrown on creation of the regexp.
      
      The commit also adds a new global V8 flag and changes an existing one:
      * --enable-experimental-engine, which turns on recognition of the RegExp
        'l' flag.  Previously this flag also caused all supported regexps to
        be executed by the experimental engine; this is not the case anymore.
      * --default-to-experimental-regexp-engine takes over the previous
        semantics of --enable-experimental-regexp-engine:  We execute all
        supported regexps with the experimental engine.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Cr-Commit-Position: refs/heads/master@{#70892}
      5720d205
  13. 19 Oct, 2020 1 commit
  14. 14 Oct, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Use experimental engine if backtrack limit exceeded · d4febb6b
      Martin Bidlingmaier authored
      We fall back from irregexp to the experimental engine if a backtrack
      limit is exceeded and the experimental engine can handle the regexp.
      The feature can be turned on with a boolean flag, and an uint-valued
      flag controls the default backtrack limit.  For regexps that are
      constructed with an explicit backtrack limit (API,
      %NewRegExpWithBacktrackLimit), we choose the lower of the explicit and
      default backtrack limits.
      The default backtrack limit does not apply to regexps that can't be
      handled by the experimental engine, and for such regexps an explicitly
      specified backtrack limit is handled as before by returning null if we
      exceed it.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70500}
      d4febb6b
  15. 07 Oct, 2020 1 commit
  16. 23 Sep, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Support the msy flags in experimental engine · e6e9cbac
      Martin Bidlingmaier authored
      The m (multiline) and s (dotall) flags just needed to be marked as
      allowed; the required logic was already in the regexp parser.
      
      A regexp /<x>/ without the y (sticky) flag is equivalent to the sticky
      regexp /.*?<x>/y.  The interpreter now assumes that every regexp is
      sticky, and the compiler appends a preamble corresponding to /.*?/
      before non-sticky regexps.  To reuse existing code for compiling this
      preamble, the logic for each kind of quantifier is now in a separate
      function and called from VisitQuantifier and for the preamble.
      
      The commit also includes some improvements/fixes for character ranges:
      - Empty character ranges/disjunctions should never match, but before
        this commit they would *always* match.
      - The check of the range bounds in CanBeHandledVisitor was unncessary;
        without the unicode flag this can't be a range that can't be specified
        in 2-byte codepoints, and once we support unicode we simply support
        all codepoints.
      - The capacity of the list containing the complementary intervals of a
        character range is now calculated more accurately.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I71a0e07279b4e1140c0ed1651b3714200c801de9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404766
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70082}
      e6e9cbac
  17. 16 Sep, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Support capture groups in experimental engine · 98b8ca89
      Martin Bidlingmaier authored
      This commit adds support for capture groups (as in e.g. /x(123|abc)y/)
      in the experimental regexp engine.  Now every InterpreterThread owns a
      register array containing (sub)match boundaries. There is a new
      instruction to record the current input index in some register.
      
      Submatches in quantifier bodies should be reported only if they occur
      during the last repetition.  Thus we reset those registers before
      attempting to match the body of a quantifier.  This is implemented with
      another new instruction.
      
      Because of concerns for the growing sizeof the NfaInterpreter object
      (which is allocated on the stack), this commit replaces the
      `SmallVector` members of the NfaInterpreter with zone-allocated arrays.
      Register arrays, which for a fixed regexp are all the same size, are
      allocated with a RecyclingZoneAllocator for cheap memory reclamation via
      a linked list of equally-sized free blocks.
      
      Possible optimizations for management of register array memory:
      1. If there are few register per thread, then it is likely faster to
         store them inline in the InterpreterThread struct.
      2. re2 implements copy-on-write:  InterpreterThreads can share the same
         register array. If a thread attempts to write to shared register
         array, the register array is cloned first.
      3. The register at index 1 contains the end of the match; this is only
         written to right before an ACCEPT statement.  We could make ACCEPT
         equivalent to what's currently CAPTURE 1 followed by ACCEPT.  We
         could then save the memory for register 1 for threads that haven't
         finished yet.  This is particularly interesting if now optimization 1
         kicks in.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I2c0503206ce331e13ac9912945bb66736d740197
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390770
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69929}
      98b8ca89
  18. 08 Sep, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Check capture_count before using experimental engine · bc4174cc
      Martin Bidlingmaier authored
      Sometimes the parser throws away redundant parts of the AST while
      parsing.  For example, the regexp /(?:(?=(f)o))?f/ is (almost)
      equivalent to just /f/ because the optional block (...)? is zero-length.
      The parser notices this and returns the same tree as for /f/.  However,
      there is a capture inside the (...)? block (which is never recorded
      because the quantifier containing it can only match zero-width, which is
      considered failure), so in this case it doesn't suffice to check that
      the regexp AST doesn't contain captures.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I6145849d95b3522a397eadd2bae63d1d8e880f28
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397896Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Cr-Commit-Position: refs/heads/master@{#69733}
      bc4174cc
  19. 01 Sep, 2020 1 commit
  20. 31 Aug, 2020 1 commit
  21. 18 Aug, 2020 1 commit