1. 11 May, 2021 1 commit
  2. 08 May, 2020 1 commit
  3. 02 Mar, 2020 1 commit
  4. 10 Feb, 2020 1 commit
  5. 04 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored
      The Factory/OffThreadFactory allows us to cleanly separate object
      construction behaviour between main-thread and off-thread in a
      syntactically consistent way (so that methods templated on the factory
      type can be made to work on both).
      
      However, there are cases where we also have to access the Isolate, for
      handle creation or exception throwing. So far we have been pushing more
      and more "customization points" into the factories to allow these
      factory-templated methods to dispatch on this isolate behaviour via
      these factory methods. Unfortunately, this is an increasing layering
      violation between Factory and Isolate, particularly around exception
      handling.
      
      Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
      way as OffThreadFactory is analogous to Factory. All methods which were
      templated on Factory are now templated on Isolate, and methods which
      used to take an Isolate, and which were recently changed to take a
      templated Factory, are changed/reverted to take a templated Isolate.
      OffThreadFactory gets an isolate() method to match Factory's.
      
      Notably, FactoryHandle is changed to "HandleFor", where the template
      argument can be either of the Isolate type or the Factory type (allowing
      us to dispatch on both depending on what is available).
      
      Bug: chromium:1011762
      Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  6. 16 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored
      Add support for internalizing an AstValueFactory using the off-thread
      factory. Includes adding ConsString support to OffThreadFactory.
      
      This introduces a Handle union wrapper, which is used in locations that
      can store a Handle or an OffThreadHandle. This is used in this patch for
      the internalized "string" field of AST strings, and will be able to be
      used for other similar fields in other classes (e.g. the ScopeInfo
      handle in Scope, object boilerplate descriptor handles, the inferred
      name handle on FunctionLiterals, etc.). It has a Factory-templated
      getter which returns the appropriate handle for the factory, and a
      debug-only tag to make sure the right getter is used at runtime. This
      union wrapper currently decomposes implicitly to a Handle if the getter
      is not called, to minimise code changes, but this implicit conversion
      will likely be removed for clarity.
      
      Bug: chromium:1011762
      Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  7. 27 Dec, 2019 1 commit
    • Daniel Clifford's avatar
      Port bitfield ScopeFlags to Torque · 7e8a197c
      Daniel Clifford authored
      In the process:
      
      * Rework the Torque definition of ScopeInfo to enable direct
        field-style access of ScopeFlags, removing some dead code in
        the process.
      * Allow implicit FromConstexpr conversion from subtypes of
        'constexpr A' to other types. This makes it possible/easy to
        convert constexpr versions of enums to other types, since the
        constexpr version of the enum isn't addressable. It's namespace
        isn't a valid namespace and is an implementation detail anyway.
      * Cleanup LanguageMode: Language mode is now an enum and directly
        mirrors the C++-side definition rather than being a Smi. With
        the changes above, a new type LanguageModeSmi is introduced
        that is the Smi representation of LanguageMode that can be
        implicitly casted from constexpr LanguageMode values.
      
      Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65561}
      7e8a197c
  8. 15 Nov, 2019 1 commit
  9. 06 Nov, 2019 1 commit
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored
      Design doc: bit.ly/v8-repl-mode
      
      This CL adds a new REPL mode that can be used via
      DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
      of 'let' bindings at the moment. Example:
      
      REPL Input 1: let x = 21;
      REPL Input 2: let x = 42;
      
      This would normally throw a SyntaxError, but works in REPL mode.
      
      The implementation is done by:
        - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
          and script {Scope}.
        - Each global let declaration still gets a slot reserved in the
          respective {ScriptContext}.
        - When a new REPL mode {ScriptContext} is created, name clashes
          for let bindings are not reported as errors.
        - Declarations, loads and stores for global let in REPL mode are
          now "load/store global" instead of accessing their respective
          context slot directly. This causes a lookup in the ScriptContextTable
          where the found slot for each name is guaranteed to be the same
          (the first one).
      
      Bug: chromium:1004193, chromium:1018158
      Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  10. 24 Sep, 2019 1 commit
  11. 11 Sep, 2019 1 commit
  12. 05 Sep, 2019 1 commit
  13. 05 Aug, 2019 1 commit
  14. 30 Jul, 2019 1 commit
    • Joyee Cheung's avatar
      [class] parse private accessors · a6dd7f1c
      Joyee Cheung authored
      This patch adds:
      
      - VariableMode::kPrivateMethod
      - VariableMode::kPrivateSetterOnly
      - VariableMode::kPrivateGetterOnly
      - VariableMode::kPrivateGetterAndSetter
      
      And replace the previous RequiresBrandCheckFlag by inferring
      whether the brand check is required from these VariableModes.
      It is then possible to check duplicate non-complementary
      accessors in the parsers and throw early errors, and allow
      complementary accessors to be associated with the same
      private name variable.
      
      This patch also adds the following AssignType:
      
      - PRIVATE_METHOD
      - PRIVATE_GETTER_ONLY
      - PRIVATE_SETTER_ONLY
      - PRIVATE_GETTER_AND_SETTER
      
      corresponding to the new VariableModes so that it's possible
      to generate specialized code for different type of
      private accessor declarations.
      
      Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
      
      Bug: v8:8330
      Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62988}
      a6dd7f1c
  15. 29 Jul, 2019 3 commits
    • 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
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored
      This reverts commit 658ff200.
      
      Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
      
      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}
      
      TBR=yangguo@chromium.org,clemensh@chromium.org
      
      Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396, v8:7629
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored
      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/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  16. 01 Jul, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Mark maybe_assigned recursively for shadowing vars · fc4bcce1
      Leszek Swirski authored
      The previous fix for this bug (crrev.com/c/1678365) pessimistically
      would mark all shadowed variables as maybe_assigned. Unfortunately,
      this doesn't work across a parse/preparse boundary, where the shadowing
      variable is found via Scope::AnalyzePartially while the shadowed
      variable is outside of the preparser entry point. In those cases, the
      referencing proxy is copied to the outer scope, in which case the
      dynamicness of the original lookup is lost and the maybe_assigned
      pessimisation no longer applies.
      
      This means that maybe_assigned status of a variable is dependent on
      which function is being parsed. In particular, it can cause bytecode
      to change on recompilation, causing issues for lazy source positions.
      
      This patch allows SetMaybeAssigned to walk its shadowed variables,
      and recursively set them to maybe_assigned too. Checking for
      maybe_assigned changing prevents this recursion from having a
      quadratic performance failure mode.
      
      Bug: v8:8510
      Bug: v8:9394
      Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62458}
      fc4bcce1
  17. 18 Jun, 2019 1 commit
  18. 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
  19. 24 May, 2019 1 commit
  20. 26 Feb, 2019 1 commit
  21. 06 Feb, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Handle 'this' with a special ThisExpression rather than VariableProxy · 3f2b5017
      Toon Verwaest authored
      "this" is a very common expression. By using a single ThisExpression object
      we can both avoid allocating many unnecessary VariableProxies and specialize
      the resolution of this since we know where it's declared up-front. This also
      avoids having to special-case "this" reference handling in the paths that would
      behave differently for "this" than for regular references; e.g., with-scopes.
      
      The tricky pieces are due to DebugEvaluate and this/super() used as default
      parameters of arrow functions. In the former case we replace the WITH_SCOPE
      with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still
      rely on regular dynamic variable lookup. Arrow functions are dealt with by
      marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression
      ends up being an arrow function, we force context allocate on the outer scope
      (and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the
      arrow function can expose "this").
      
      The CL also removes the now unused ThisFunction AST node.
      
      Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef
      Reviewed-on: https://chromium-review.googlesource.com/c/1448313Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59393}
      3f2b5017
  22. 25 Jan, 2019 1 commit
  23. 21 Jan, 2019 2 commits
  24. 10 Jan, 2019 1 commit
  25. 02 Nov, 2018 1 commit
  26. 27 Sep, 2018 1 commit
  27. 03 Sep, 2018 1 commit
  28. 29 May, 2018 1 commit
  29. 13 Oct, 2017 1 commit
  30. 26 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · 777da354
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46229}
      777da354
  31. 25 Jun, 2017 1 commit
  32. 23 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · d00d52be
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46191}
      d00d52be
  33. 22 Jun, 2017 1 commit
  34. 08 May, 2017 1 commit
    • Adam Klein's avatar
      Skip hole initialization of lexical variables when possible · ededfcd2
      Adam Klein authored
      This patch expands scope analysis to skip hole initialization
      when it can be determined statically that no hole checks will
      be generated at runtime.
      
      Two conditions must be met to safely eliminate hole initialization:
        - There must not exist a VariableProxy referencing this Variable
          whose HoleCheckMode is kRequired
        - The Variable must be stack allocated; any other allocation implies
          that it may be accessed from not-yet-analyzed scopes (other modules,
          inner functions, or eval code) and that code may require
          hole checks.
      
      The new logic required removing debug code in full-codegen which is
      now incorrect in some cases.
      
      Also fixed Variable's bitfield helpers to take no more space than needed.
      
      Bug: chromium:651637
      Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d
      Reviewed-on: https://chromium-review.googlesource.com/494006
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45170}
      ededfcd2
  35. 30 Mar, 2017 1 commit
  36. 04 Nov, 2016 2 commits
    • verwaest's avatar
      Preparse lazy function parameters · 4ff2cafe
      verwaest authored
      Parameters of a lazily parsed function used to be parsed eagerly, and parameter
      handling was split between Parser::ParseFunctionLiteral and
      ParseEagerFunctionBody, leading to inconsistencies.
      
      After this CL, we preparse (lazy parse) the parameters of lazily parsed
      functions.
      
      (For arrow functions, we cannot do that ofc.)
      
      This is needed for later features (PreParser with scope analysis).
      
      -- CL adapted from marja's https://codereview.chromium.org/2411793003/
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2472063002
      Cr-Commit-Position: refs/heads/master@{#40771}
      4ff2cafe
    • neis's avatar
      [modules] Assign cell indices at validation time. · 1dd241c4
      neis authored
      Instead of having a MODULE variable's index be 0 or 1, let it be the index of
      its cell.  In this CL, we assign the indices but we continue to only use them to
      distinguish imports from exports.  Actually using them to directly access the
      cells will be done in a later CL.
      
      R=adamk@chromium.org
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2460233003
      Cr-Commit-Position: refs/heads/master@{#40752}
      1dd241c4