1. 24 Jun, 2021 3 commits
  2. 18 Jun, 2021 1 commit
  3. 11 Jun, 2021 1 commit
    • Dan Elphick's avatar
      [build] Reduce size of inline header cycles · c26965bd
      Dan Elphick authored
      This removes/replaces header includes with the aim of shrinking the
      size of the inline header cycle. Specifically before this CL, there was
      a single Strongly-Connected Component comprising 60 header files from
      src/objects and src/heap.
      
      Now there are two 2 SCCs. The src/heap SCC has 6 files and depends on
      the src/objects SCC, which has 50 files. Additionally some previously
      implicit dependencies have been added.
      
      Dependencies calculated using:
      git grep "#include \"" *.h *.cc | sed 's/:#include "/ /;s/".*$//' | \
      awk 'BEGIN {print "digraph deps {" } END {print "}"} {print "\""$1"\" -> \""$2"\""}'
      
      SCCs found using sccmap from graphviz.
      
      Also removes unused Cell::FromValueAddress method.
      
      Change-Id: Ib19d00ccd14e490ee64d57be4d99b1b3686ac32a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951734Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75103}
      c26965bd
  4. 04 May, 2021 1 commit
  5. 08 Mar, 2021 1 commit
  6. 25 Feb, 2021 1 commit
  7. 11 Feb, 2021 1 commit
  8. 25 Nov, 2020 1 commit
  9. 24 Nov, 2020 1 commit
  10. 20 Nov, 2020 1 commit
  11. 11 Nov, 2020 1 commit
  12. 21 Oct, 2020 1 commit
  13. 20 Oct, 2020 1 commit
  14. 05 Oct, 2020 1 commit
  15. 02 Oct, 2020 1 commit
  16. 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
  17. 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
  18. 07 Sep, 2020 1 commit
  19. 17 Aug, 2020 1 commit
  20. 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
  21. 12 Jun, 2020 1 commit
  22. 29 Apr, 2020 2 commits
  23. 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
  24. 17 Feb, 2020 1 commit
  25. 16 Jan, 2020 1 commit
  26. 25 Nov, 2019 3 commits
  27. 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
  28. 21 Nov, 2019 1 commit
  29. 18 Nov, 2019 1 commit
  30. 15 Nov, 2019 1 commit
  31. 31 Oct, 2019 1 commit
  32. 24 Oct, 2019 2 commits
  33. 22 Oct, 2019 1 commit
  34. 15 Oct, 2019 1 commit