1. 13 Oct, 2017 1 commit
  2. 17 Mar, 2017 1 commit
  3. 09 Sep, 2016 1 commit
  4. 27 Aug, 2016 1 commit
    • verwaest's avatar
      Revert of Always deserialize scope infos for parsing (patchset #3 id:40001 of... · f046cb95
      verwaest authored
      Revert of Always deserialize scope infos for parsing (patchset #3 id:40001 of https://codereview.chromium.org/2280933002/ )
      
      Reason for revert:
      Significantly tanks parsing. We probably should just keep on doing what we're doing: partially deserialize while resolving variables. If we do scope-info backed resolution after regular resolution based on remaining free variables, we can probably reduce the time-frame of that part. We soon after anyway need to sync with the main thread.
      
      Original issue's description:
      > Always deserialize scope infos for parsing
      >
      > When looking up variables in the ScopeInfo, we did a linear scan of the
      > ScopeInfo. Since that's unacceptably slow, a context slot cache was added
      > that would speed up repeated lookups of the same variable.
      >
      > Instead, just always fully convert the ScopeInfo into scopes, so they can
      > lookup variables without scanning the ScopeInfo.
      >
      > This also allows for removing the now unused ContextSlotCache.
      >
      > R=adamk@chromium.org,verwaest@chromium.org,marja@chromium.org
      > BUG=v8:5315
      >
      > Committed: https://crrev.com/81f824cad18e4dc873a8838943217eb9c9f0c1f0
      > Cr-Commit-Position: refs/heads/master@{#38953}
      
      TBR=adamk@chromium.org,marja@chromium.org,jochen@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5315
      
      Review-Url: https://codereview.chromium.org/2287783003
      Cr-Commit-Position: refs/heads/master@{#38958}
      f046cb95
  5. 26 Aug, 2016 1 commit
    • jochen's avatar
      Always deserialize scope infos for parsing · 81f824ca
      jochen authored
      When looking up variables in the ScopeInfo, we did a linear scan of the
      ScopeInfo. Since that's unacceptably slow, a context slot cache was added
      that would speed up repeated lookups of the same variable.
      
      Instead, just always fully convert the ScopeInfo into scopes, so they can
      lookup variables without scanning the ScopeInfo.
      
      This also allows for removing the now unused ContextSlotCache.
      
      R=adamk@chromium.org,verwaest@chromium.org,marja@chromium.org
      BUG=v8:5315
      
      Review-Url: https://codereview.chromium.org/2280933002
      Cr-Commit-Position: refs/heads/master@{#38953}
      81f824ca
  6. 01 Aug, 2016 1 commit
  7. 28 Jun, 2016 1 commit
  8. 26 Nov, 2015 1 commit
  9. 30 Sep, 2015 1 commit
  10. 10 Sep, 2015 1 commit
  11. 06 Jul, 2015 1 commit
  12. 18 Feb, 2015 1 commit
    • adamk's avatar
      Rename Interface to ModuleDescriptor · 27e8a455
      adamk authored
      ModuleDescriptor will end up holding the set of data described in the
      spec as a "Module record". This introduces a little bit of confusion
      with ModuleInfo, but I hope that'll become clearer over time.
      
      Also removed the interface-printing flags. We probably want
      Module-printing flags, but that can wait until we have more
      Module-related structures.
      
      BUG=v8:1569
      LOG=n
      
      Review URL: https://codereview.chromium.org/935723004
      
      Cr-Commit-Position: refs/heads/master@{#26728}
      27e8a455
  13. 17 Feb, 2015 1 commit
  14. 29 Jan, 2015 1 commit
  15. 04 Aug, 2014 1 commit
  16. 30 Jul, 2014 1 commit
  17. 03 Jun, 2014 1 commit
  18. 30 Apr, 2014 1 commit
  19. 29 Apr, 2014 1 commit
  20. 22 Nov, 2012 1 commit
    • rossberg@chromium.org's avatar
      Get rid of static module allocation, do it in code. · ce05280b
      rossberg@chromium.org authored
      Modules now have their own local scope, represented by their own context.
      Module instance objects have an accessor for every export that forwards
      access to the respective slot from the module's context. (Exports that are
      modules themselves, however, are simple data properties.)
      
      All modules have a _hosting_ scope/context, which (currently) is the
      (innermost) enclosing global scope. To deal with recursion, nested modules
      are hosted by the same scope as global ones.
      
      For every (global or nested) module literal, the hosting context has an
      internal slot that points directly to the respective module context. This
      enables quick access to (statically resolved) module members by 2-dimensional
      access through the hosting context. For example,
      
        module A {
          let x;
          module B { let y; }
        }
        module C { let z; }
      
      allocates contexts as follows:
      
      [header| .A | .B | .C | A | C ]  (global)
                |    |    |
                |    |    +-- [header| z ]  (module)
                |    |
                |    +------- [header| y ]  (module)
                |
                +------------ [header| x | B ]  (module)
      
      Here, .A, .B, .C are the internal slots pointing to the hosted module
      contexts, whereas A, B, C hold the actual instance objects (note that every
      module context also points to the respective instance object through its
      extension slot in the header).
      
      To deal with arbitrary recursion and aliases between modules,
      they are created and initialized in several stages. Each stage applies to
      all modules in the hosting global scope, including nested ones.
      
      1. Allocate: for each module _literal_, allocate the module contexts and
         respective instance object and wire them up. This happens in the
         PushModuleContext runtime function, as generated by AllocateModules
         (invoked by VisitDeclarations in the hosting scope).
      
      2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
         assign the respective instance object to respective local variables. This
         happens in VisitModuleDeclaration, and uses the instance objects created
         in the previous stage.
         For each module _literal_, this phase also constructs a module descriptor
         for the next stage. This happens in VisitModuleLiteral.
      
      3. Populate: invoke the DeclareModules runtime function to populate each
         _instance_ object with accessors for it exports. This is generated by
         DeclareModules (invoked by VisitDeclarations in the hosting scope again),
         and uses the descriptors generated in the previous stage.
      
      4. Initialize: execute the module bodies (and other code) in sequence. This
         happens by the separate statements generated for module bodies. To reenter
         the module scopes properly, the parser inserted ModuleStatements.
      
      R=mstarzinger@chromium.org,svenpanne@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/11093074
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ce05280b
  21. 03 Nov, 2011 2 commits
  22. 21 Oct, 2011 1 commit
    • keuchel@chromium.org's avatar
      Reapply r9673 "Scope tree serialization and ScopeIterator cleanup." · 666c4be2
      keuchel@chromium.org authored
      This also includes the two fixes from r9674 and r9675. Here's the diff
      to the previous CL.
      
       --- a/src/runtime.cc
       +++ b/src/runtime.cc
       @@ -11133,17 +11133,26 @@ class ScopeIterator {
              context_(Context::cast(frame->context())),
              nested_scope_chain_(4) {
      
       +    // Catch the case when the debugger stops in an internal function.
       +    Handle<SharedFunctionInfo> shared_info(function_->shared());
       +    if (shared_info->script() == isolate->heap()->undefined_value()) {
       +      if (shared_info->scope_info()->HasContext()) Next();
       +      return;
       +    }
       +
            // Check whether we are in global code or function code. If there is a stack
            // slot for .result then this function has been created for evaluating
            // global code and it is not a real function.
            // Checking for the existence of .result seems fragile, but the scope info
            // saved with the code object does not otherwise have that information.
       -    int index = function_->shared()->scope_info()->
       +    int index = shared_info->scope_info()->
                StackSlotIndex(isolate_->heap()->result_symbol());
      
            // Reparse the code and analyze the scopes.
            ZoneScope zone_scope(isolate, DELETE_ON_EXIT);
       -    Handle<SharedFunctionInfo> shared_info(function_->shared());
            Handle<Script> script(Script::cast(shared_info->script()));
            Scope* scope;
            if (index >= 0) {
      
      Review URL: http://codereview.chromium.org/8344046
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      666c4be2
  23. 19 Oct, 2011 1 commit
  24. 18 Oct, 2011 1 commit
  25. 11 Oct, 2011 1 commit
  26. 08 Sep, 2011 1 commit
  27. 11 Aug, 2011 1 commit
  28. 16 Jun, 2011 2 commits
  29. 15 Jun, 2011 1 commit
  30. 11 May, 2011 1 commit
  31. 06 May, 2011 1 commit
  32. 11 Apr, 2011 1 commit
  33. 18 Mar, 2011 3 commits
  34. 07 Dec, 2010 3 commits