1. 21 Oct, 2020 1 commit
  2. 15 Nov, 2019 1 commit
  3. 22 Oct, 2019 1 commit
  4. 29 Jul, 2019 1 commit
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored
      This is a reland of 658ff200
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      Bug: v8:9396, v8:7629
      Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
  5. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  6. 24 May, 2019 1 commit
  7. 23 May, 2019 1 commit
  8. 21 May, 2019 1 commit
  9. 06 May, 2019 1 commit
  10. 03 May, 2019 1 commit
    • Sigurd Schneider's avatar
      Revert "Reland "[json] Speed up json parsing"" · 47fccbfd
      Sigurd Schneider authored
      This reverts commit bbd740f0.
      
      Reason for revert: blocks lkgr due to layout test failure:
      https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/31607
      
      Original change's description:
      > Reland "[json] Speed up json parsing"
      > 
      > This is a reland of b0c4a876
      > 
      > Original change's description:
      > > [json] Speed up json parsing
      > >
      > > - scan using raw data pointers + GC callback
      > > - scan using scanner tables
      > > - cap internalizing large string values
      > > - inline fast transitioning logic
      > >
      > > Fixes previous CL by moving AllowHeapAllocation to callers of
      > > ReportUnexpectedCharacter where needed to make it clear we need to exit.
      > >
      > > Tbr: ulan@chromium.org
      > > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#61159}
      > 
      > Tbr: verwaest@chromium.org
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      > Change-Id: Ic7d0057178c649fc45b8c8f4587ee9128e351515
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593292
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61179}
      
      TBR=ulan@chromium.org,ishell@google.com,verwaest@google.com,ishell@chromium.org,verwaest@chromium.org
      
      Change-Id: I3ae8f9ce8214bebe7fab9d87c5daf8cdfdb94199
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594438
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61194}
      47fccbfd
  11. 02 May, 2019 3 commits
  12. 30 Apr, 2019 4 commits
  13. 26 Apr, 2019 1 commit
  14. 04 Apr, 2019 1 commit
  15. 03 Apr, 2019 1 commit
  16. 06 Feb, 2019 1 commit
  17. 05 Feb, 2019 1 commit
  18. 04 Feb, 2019 1 commit
  19. 19 Sep, 2018 1 commit
  20. 03 Jul, 2018 1 commit
  21. 21 Jun, 2018 1 commit
  22. 15 Feb, 2018 1 commit
  23. 11 Dec, 2017 1 commit
    • Justin Ridgewell's avatar
      Implement DFA Unicode Decoder · cedec225
      Justin Ridgewell authored
      This is a separation of the DFA Unicode Decoder from
      https://chromium-review.googlesource.com/c/v8/v8/+/789560
      
      I attempted to make the DFA's table a bit more explicit in this CL. Still, the
      linter prevents me from letting me present the array as a "table" in source
      code. For a better representation, please refer to
      https://docs.google.com/spreadsheets/d/1L9STtkmWs-A7HdK5ZmZ-wPZ_VBjQ3-Jj_xN9c6_hLKA
      
      - - - - -
      
      Now for a big copy-paste from 789560:
      
      Essentially, reworks a standard FSM (imagine an
      array of structs) and flattens it out into a single-dimension array.
      Using Table 3-7 of the Unicode 10.0.0 standard (page 126 of
      http://www.unicode.org/versions/Unicode10.0.0/ch03.pdf), we can nicely
      map all bytes into one of 12 character classes:
      
      00. 0x00-0x7F
      01. 0x80-0x8F (split from general continuation because this range is not
          valid after a 0xF0 leading byte)
      02. 0x90-0x9F (split from general continuation because this range is not
          valid after a 0xE0 nor a 0xF4 leading byte)
      03. 0xA0-0xBF (the rest of the continuation range)
      04. 0xC0-0xC1, 0xF5-0xFF (the joined range of invalid bytes, notice this
          includes 255 which we use as a known bad byte during hex-to-int
              decoding)
      05. 0xC2-0xDF (leading bytes which require any continuation byte
          afterwards)
      06. 0xE0 (leading byte which requires a 0xA0-0xBF afterwards then any
          continuation byte after that)
      07. 0xE1-0xEC, 0xEE-0xEF (leading bytes which requires any continuation
          afterwards then any continuation byte after that)
      08. 0xED (leading byte which requires a 0x80-0x9F afterwards then any
          continuation byte after that)
      09. 0xF1-F3 (leading bytes which requires any continuation byte
          afterwards then any continuation byte then any continuation byte)
      10. 0xF0 (leading bytes which requires a 0x90-0xBF afterwards then any
          continuation byte then any continuation byte)
      11. 0xF4 (leading bytes which requires a 0x80-0x8F afterwards then any
          continuation byte then any continuation byte)
      
      Note that 0xF0 and 0xF1-0xF3 were swapped so that fewer bytes were
      needed to represent the transition state ("9, 10, 10, 10" vs.
      "10, 9, 9, 9").
      
      Using these 12 classes as "transitions", we can map from one state to
      the next. Each state is defined as some multiple of 12, so that we're
      always starting at the 0th column of each row of the FSM. From each
      state, we add the transition and get a index of the new row the FSM is
      entering.
      
      If at any point we encounter a bad byte, the state + bad-byte-transition
      is guaranteed to map us into the first row of the FSM (which contains no
      valid exiting transitions).
      
      The key differences from Björn's original (or his self-modified) DFA is
      the "bad" state is now mapped to 0 (or the first row of the FSM) instead
      of 12 (the second row). This saves ~50 bytes when gzipping, and also
      speeds up determining if a string is properly encoded (see his sample
      code at http://bjoern.hoehrmann.de/utf-8/decoder/dfa/#performance).
      
      Finally, I've replace his ternary check with an array access, to make
      the algorithm branchless. This places a requirement on the caller to 0
      out the code point between successful decodings, which it could always
      have done because it's already branching.
      
      R=marja@google.com
      
      Bug: 
      Change-Id: I574f208a84dc5d06caba17127b0d41f7ce1a3395
      Reviewed-on: https://chromium-review.googlesource.com/805357
      Commit-Queue: Justin Ridgewell <jridgewell@google.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50012}
      cedec225
  24. 02 Oct, 2017 1 commit
    • Mathias Bynens's avatar
      [parser] Add use counter for U+2028 & U+2029 · d3c98121
      Mathias Bynens authored
      The context is the following proposal to make JSON a subset of
      JavaScript: https://github.com/tc39/proposal-json-superset
      
      There’s interest in performing a side investigation to answer the
      question of what would happen if we stopped treating U+2028 and U+2029
      as `LineTerminator`s *entirely*. (Note that this is separate from the
      proposal, which just changes how these characters are handled in
      ECMAScript strings.) This is technically a breaking change, and IMHO it
      would be wonderful if we could get away with it, but no one really has
      any data on whether or not we could. Adding this use counter lets us get
      that data.
      
      BUG=v8:6827
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa
      Reviewed-on: https://chromium-review.googlesource.com/693155
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48260}
      d3c98121
  25. 29 Sep, 2017 1 commit
  26. 05 Sep, 2017 1 commit
  27. 29 Jun, 2017 1 commit
  28. 14 Jun, 2017 1 commit
    • jshin's avatar
      Use ICU for ID_START, ID_CONTINUE and WhiteSpace check · 4aeb94a4
      jshin authored
      Use ICU to check ID_Start, ID_Continue and WhiteSpace even for BMP
      when V8_INTL_SUPPORT is on (which is default).
      
      Change LineTerminator::Is() to check 4 code points from
      ES#sec-line-terminators instead of using tables and Lookup function.
      
      Remove Lowercase::Is(). It's not used anywhere.
      
      Update webkit/{ToNumber,parseFloat}.js to have the correct expectation
      for U+180E and the corresponding expected files. This is a follow-up to
      an earlier change ( https://codereview.chromium.org/2720953003 ).
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe
      CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
      
      BUG=v8:5370,v8:5155
      TEST=unittests --gtest_filter=CharP*
      TEST=webkit: ToNumber, parseFloat
      TEST=test262: built-ins/Number/S9.3*, built-ins/parse{Int,Float}/S15*
      TEST=test262: language/white-space/mong*
      TEST=test262: built-ins/String/prototype/trim/u180e
      TEST=mjsunit: whitespaces
      
      Review-Url: https://codereview.chromium.org/2331303002
      Cr-Commit-Position: refs/heads/master@{#45957}
      4aeb94a4
  29. 23 May, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Also kBadChar is a valid utf8 character · 8e0daf78
      Andreas Haas authored
      The validation of utf8 strings in WebAssembly modules used the character
      kBadChar = 0xFFFD to indicate a validation error. However, this
      character can appear in a valid utf8 string. This CL fixes this problem
      by duplicating some of the code in {Utf8::CalculateValue} and inlining
      it directly into Utf8::Validate. Note that Utf8::Validate is used only
      for WebAssembly.
      
      Tests for this change are in the WebAssembly spec tests, which I will
      update in a separate CL.
      
      R=vogelheim@chromium.org
      
      Change-Id: I8697b9299f3e98a8eafdf193bff8bdff90efd7dc
      Reviewed-on: https://chromium-review.googlesource.com/509534Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45476}
      8e0daf78
  30. 17 Oct, 2016 1 commit
  31. 05 Oct, 2016 1 commit
  32. 16 Sep, 2016 1 commit
    • vogelheim's avatar
      Rework scanner-character-streams. · 642d6d31
      vogelheim authored
      - Smaller, more consistent streams API (Advance, Back, pos, Seek)
      - Remove implementations from the header, in favor of creation functions.
      
      Observe:
      - Performance:
        - All Utf16CharacterStream methods have an inlinable V8_LIKELY w/ a
          body of only a few instructions. I expect most calls to end up there.
        - There used to be performance problems w/ bookmarking, particularly
          with copying too much data on SetBookmark w/ UTF-8 streaming streams.
          All those copies are gone.
        - The old streaming streams implementation used to copy data even for
          2-byte input. It no longer does.
        - The only remaining 'slow' method is the Seek(.) slow case for utf-8
          streaming streams. I don't expect this to be called a lot; and even if,
          I expect it to be offset by the gains in the (vastly more frequent)
          calls to the other methods or the 'fast path'.
        - If it still bothers us, there are several ways to speed it up.
      - API & code cleanliness:
        - I want to remove the 'old' API in a follow-up CL, which should mostly
          delete code, or replace it 1:1.
        - In a 2nd follow-up I want to delete much of the UTF-8 handling in Blink
          for streaming streams.
        - The "bookmark" is now always implemented (and mostly very fast), so we
          should be able to use it for more things.
      - Testing & correctness:
        - The unit tests now cover all stream implementations,
          and are pretty good and triggering all the edge cases.
        - Vastly more DCHECKs of the invariants.
      
      BUG=v8:4947
      
      Review-Url: https://codereview.chromium.org/2314663002
      Cr-Commit-Position: refs/heads/master@{#39464}
      642d6d31
  33. 12 May, 2016 1 commit
    • clemensh's avatar
      [wasm] Add UTF-8 validation · f0523e30
      clemensh authored
      Names passed for imports and exports are checked during decoding,
      leading to errors if they are no valid UTF-8. Function names are not
      checked during decode, but rather lead to undefined being returned at
      runtime if they are not UTF-8.
      
      We need to do these checks on the Wasm side, since the factory
      methods assume to get valid UTF-8 strings.
      
      R=titzer@chromium.org, yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/1967023004
      Cr-Commit-Position: refs/heads/master@{#36208}
      f0523e30
  34. 02 Feb, 2016 2 commits