1. 11 Feb, 2021 1 commit
  2. 25 Nov, 2020 1 commit
  3. 24 Nov, 2020 1 commit
  4. 20 Nov, 2020 1 commit
  5. 11 Nov, 2020 1 commit
  6. 21 Oct, 2020 1 commit
  7. 20 Oct, 2020 1 commit
  8. 05 Oct, 2020 1 commit
  9. 02 Oct, 2020 1 commit
  10. 23 Sep, 2020 1 commit
    • Leszek Swirski's avatar
      [handles] Add a PatchValue method for Handle · ba088da2
      Leszek Swirski authored
      We currently have a pattern of setting a dereferenced Handle location to
      update that Handle's value:
      
        *handle.location() = new_value.ptr()
      
      This is slightly opaque, and definitely not type-safe, so add a new
      Handle<T>::PatchValue method which does this operation.
      
      Ideally we would make Handle::location() return a const pointer to
      discourage this sort of use, but there's a bunch of places where that
      location pointer is used and passed around as a Handle surrogate, so
      those would have to be updated first.
      
      Change-Id: I157f7e2473ed1b86f7a93cae260b0932fed0ad88
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424249
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70088}
      ba088da2
  11. 21 Sep, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Support assertions in experimental engine · e83511c2
      Martin Bidlingmaier authored
      Assertions are implemented with the new ASSERTION instruction.  The nfa
      interpreter evaluates the assertion based on the current context in the
      subject string every time a thread executes ASSERTION.  This is
      analogous to what re2 and rust/regex do.
      
      Alternatives to this approach:
      - The interpreter could calculate eagerly for all assertion types
        whether they are satisfied whenever the current input position is
        advanced.  This would make evaluating the ASSERTION instruction itself
        cheaper, but at the cost of making every advance in the input string
        more expensive.  I suspect this would be slower on average because
        assertions are not that common that we typically evaluate >= 2
        assertions at every input position.
      - Assertions in a regexp could be desugared into CONSUME_RANGE
        instructions, so that no new instruction would be necessary.  For
        example, the word boundary assertion \b is satisfied at a given
        position/state if we have just consumed a word character and will
        consume a non-word character next, or vice-versa.  The tricky part
        about this is that the assertion itself should not consume input, so
        we'd have to split (automaton) states according to whether we've
        arrived at them via a word character or not.  The current compiler is
        not really equipped for this kind of transformation.  For {start,end}
        of {line,file} assertions, we'd need to introduce dummy characters
        indicating start/end of input (say, 0x10000 and 0x10001) which we feed
        to the interpreter before respectively after the actual input.
        I suspect that this approach wouldn't make much of a difference for
        NFA execution. It would likely speed up (lazy) DFA execution though
        because assertions would be dealt with in the fast path.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: Ic2012c943e0ce54eb8662789fb3d4c1b6cd8d606
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398644
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70026}
      e83511c2
  12. 07 Sep, 2020 1 commit
  13. 17 Aug, 2020 1 commit
  14. 20 Jul, 2020 1 commit
    • Etienne Pierre-Doray's avatar
      Revert "[Jank]: Add uri trace events" · 3883b29a
      Etienne Pierre-Doray authored
      This reverts commit d1aee56d.
      
      Reason for revert: Trace event is causing telemetry regressions
      (crbug.com/1094957).
      I got a few days of traces and didn't really find what I was looking for, so I'll find another way to investigate.
      
      Original change's description:
      > [Jank]: Add uri trace events
      > 
      > To investigate jank found in UMA sampling profiler.
      > 
      > Bug: chromium:1081433
      > Change-Id: I457731380505af5a4d7a0c30d01b4049ffd2b436
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242037
      > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68326}
      
      TBR=leszeks@chromium.org,etiennep@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1081433, chromium:1094957
      Change-Id: I6c9573e9a77a54255c5fadc3cec14d437fd62b45
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2279135
      Auto-Submit: Etienne Pierre-Doray <etiennep@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68949}
      3883b29a
  15. 12 Jun, 2020 1 commit
  16. 29 Apr, 2020 2 commits
  17. 17 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [base] Fix {StaticCharVector} and add {StaticOneByteVector} · e04eb281
      Clemens Backes authored
      {StaticCharVector}, according to its name, should return a
      {Vector<const char>}. For getting a {Vector<const uint8_t>}, the method
      should be called {StaticOneByteVector}, analog to the
      {OneByteVector} methods that already exist.
      
      Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot
      be, since it contains a {reinterpret_cast}. The same holds for
      {Vector::cast} in general.
      
      This CL
      - changes the return type of {StaticCharVector} to be
        {Vector<const char>},
      - introduces a new {StaticOneByteVector} which returns
        {Vector<const uint8_t>},
      - fixes constexpr annotations at various methods returning {Vector}s,
      - refactors users of {StaticCharVector} to either use
        {StaticOneByteVector} instead, or work on {char} if that makes more
        sense.
      
      R=leszeks@chromium.org
      
      Bug: v8:10426
      Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67213}
      e04eb281
  18. 17 Feb, 2020 1 commit
  19. 16 Jan, 2020 1 commit
  20. 25 Nov, 2019 3 commits
  21. 22 Nov, 2019 1 commit
    • Clemens Backes's avatar
      Hash all strings as unsigned values · caf005e8
      Clemens Backes authored
      A previous CL (https://crrev.com/c/1926769) changed hashing to always
      treat the input as signed values. This causes problems, since the hash
      of a one-byte string differs the hash of the identical two-byte string.
      Hence this CL switches to treating all values as unsigned in hashing.
      
      The bug cannot easily be reproduced in v8 alone, since we would need to
      create an internalized two-byte string, which contains one-byte data.
      Blink manages to create such a string via external strings.
      
      R=jkummerow@chromium.org
      
      Bug: chromium:1025184, chromium:1027131
      Change-Id: Id41aa0e463691c02099a08c6e9d837a079c872df
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930615Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65113}
      caf005e8
  22. 21 Nov, 2019 1 commit
  23. 18 Nov, 2019 1 commit
  24. 15 Nov, 2019 1 commit
  25. 31 Oct, 2019 1 commit
  26. 24 Oct, 2019 2 commits
  27. 22 Oct, 2019 1 commit
  28. 15 Oct, 2019 1 commit
  29. 11 Oct, 2019 1 commit
  30. 08 Oct, 2019 1 commit
  31. 18 Sep, 2019 1 commit
  32. 17 Sep, 2019 2 commits
    • Adam Klein's avatar
      Revert "Reland "Remove all custom CopyCharsUnsigned implementations"" · 24c35b92
      Adam Klein authored
      This reverts commits 9febc505
      (along with followup commit 60624b56).
      
      Reason for revert: Breaks win32 nosnap shared, blocking lkgr & roll:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/35145
      
      nosnap bots may be deprecated, but as long as they're in LKGR
      we need to mind them.
      
      Original change's description:
      > Reland "Remove all custom CopyCharsUnsigned implementations"
      >
      > This is a reland of 5d8c4890
      >
      > Original change's description:
      > > Remove all custom CopyCharsUnsigned implementations
      > >
      > > It's unclear whether the custom implementation have any advantage over
      > > the standard library one's.
      > > Since we update our toolchain and standard library regularly, it might
      > > well be the case that the custom implementations are slower by now.
      > >
      > > Thus this CL removes all {CopyCharsUnsigned} implementations and
      > > implements {CopyChars} generically using {std::copy_n}.
      > >
      > > Note that this does not touch the {MemMove} and {MemCopy} functions
      > > yet, as we have seen regressions when trying to remove them before
      > > (https://crbug.com/v8/8675#c5).
      > >
      > > R=leszeks@chromium.org
      > >
      > > Bug: v8:9396
      > > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63808}
      >
      > Bug: v8:9396
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      > Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63823}
      
      TBR=leszeks@chromium.org,clemensh@chromium.org
      
      Change-Id: Ic53ab2293d5dc7722a1121d1aa1159328a6ed8f5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808035Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63854}
      24c35b92
    • Clemens Hammacher's avatar
      Disallow nullptr arguments for {CopyChars} · 60624b56
      Clemens Hammacher authored
      This allows to remove special casing for the {count == 0} case, which
      was needed because {memmove} does not accept {nullptr} arguments even
      if the {count} is zero.
      
      R=leszeks@chromium.org
      
      Bug: v8:9396
      Change-Id: Iaef3cdbbffa74c2ba1c4e4501dafd943282cbcd9
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807366Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63838}
      60624b56
  33. 13 Sep, 2019 1 commit
  34. 21 Aug, 2019 1 commit
  35. 06 Aug, 2019 1 commit