1. 11 Mar, 2014 2 commits
  2. 27 Feb, 2014 1 commit
  3. 12 Feb, 2014 1 commit
    • rafaelw@chromium.org's avatar
      V8 Microtask Queue & API · 6b5a4cde
      rafaelw@chromium.org authored
      This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue".
      
      It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to
      
      -schedule a microtask (EnqueueExternalMicrotask)
      -run the microtask queue (RunMicrotasks)
      -control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks).
      
      R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne
      BUG=
      
      Review URL: https://codereview.chromium.org/154283002
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      6b5a4cde
  4. 24 Jan, 2014 1 commit
  5. 27 Nov, 2013 1 commit
  6. 22 Nov, 2013 1 commit
  7. 21 Nov, 2013 2 commits
  8. 04 Sep, 2013 1 commit
  9. 03 Sep, 2013 1 commit
  10. 21 Jun, 2013 1 commit
  11. 04 Jun, 2013 1 commit
  12. 13 May, 2013 1 commit
  13. 10 May, 2013 1 commit
    • wingo@igalia.com's avatar
      Remove separate maps for function instances · 3f09e0a3
      wingo@igalia.com authored
      ES3 specified that functions created via Function() would have
      enumerable prototypes, unlike function literals.  For this reason, V8
      has always had two prototypes for functions: "function_map" for
      literals, and "function_instance_map" for "function instances": those
      functions created by Function().
      
      However, since 2009 or so, both maps have been the same!  Both have had
      writable, non-enumerable prototypes.  Moreover, ES5 changed to specify
      that function instances would have non-enumerable prototypes.
      
      This patch removes the separate maps for function instances in sloppy
      and strict mode.
      
      R=mstarzinger@chromium.org
      TEST=mjsunit/function-prototype
      BUG=
      
      Review URL: https://codereview.chromium.org/14829005
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      3f09e0a3
  14. 07 May, 2013 1 commit
  15. 02 May, 2013 1 commit
  16. 29 Apr, 2013 1 commit
  17. 25 Apr, 2013 1 commit
  18. 11 Apr, 2013 1 commit
    • rossberg@chromium.org's avatar
      * src/generator.js: Add methods and intialization for generator meta-objects. · 8e8bbc0e
      rossberg@chromium.org authored
      * src/contexts.h:
      * src/bootstrapper.cc (InitializeExperimentalGlobal): Make generator
        meta-objects, and store maps for constructing generator functions
        and their prototypes.
      
      * src/factory.h:
      * src/factory.cc (MapForNewFunction): New helper.
        (NewFunctionFromSharedFunctionInfo): Use the new helper.
      
      * src/heap.cc (AllocateFunctionPrototype, AllocateInitialMap): For
         generators, allocate appropriate prototypes and maps.
      
      * src/code-stubs.h:
      * src/arm/code-stubs-arm.h:
      * src/arm/full-codegen-arm.h:
      * src/ia32/code-stubs-ia32.h:
      * src/ia32/full-codegen-ia32.h:
      * src/x64/code-stubs-x64.h:
      * src/x64/full-codegen-x64.h: Allow fast closure creation for generators,
      using the appropriate map.
      
      * test/mjsunit/harmony/builtins.js: Add a special case for
        GeneratorFunctionPrototype.prototype.__proto__.
      
      BUG=
      TEST=mjsunit/harmony/generators-runtime
      
      Review URL: https://codereview.chromium.org/13192004
      
      Patch from Andy Wingo <wingo@igalia.com>.
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14236 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      8e8bbc0e
  19. 22 Mar, 2013 1 commit
  20. 01 Mar, 2013 1 commit
    • rossberg@chromium.org's avatar
      ES6 symbols: Implement Symbol intrinsic and basic functionality · 090d09d6
      rossberg@chromium.org authored
      - Add --harmony-symbols flag.
      - Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
      - Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
      - Extend 'typeof' code generation to handle symbols.
      - Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
      - Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
      - Extend Object.prototype.toString to recognise symbols.
      
      Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
      
      (Baseline CL: https://codereview.chromium.org/12223071/)
      
      R=mstarzinger@chromium.org
      BUG=v8:2158
      
      Review URL: https://codereview.chromium.org/12296026
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      090d09d6
  21. 07 Dec, 2012 1 commit
  22. 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
  23. 13 Nov, 2012 1 commit
  24. 09 Nov, 2012 1 commit
  25. 08 Nov, 2012 1 commit
    • rossberg@chromium.org's avatar
      Delivery logic for Object.observe · c203f054
      rossberg@chromium.org authored
      This CL has two parts: the first is the logic itself, whereby each observer callback is assigned
      a "priority" number the first time it's passed as an observer to Object.observe(), and that
      priority is used to determine the order of delivery.
      
      The second part invokes the above logic as part of the API, when the JS stack winds down to
      zero.
      
      Added several tests via the API, as the delivery logic isn't testable from a JS test
      (it runs after such a test would exit).
      
      Review URL: https://codereview.chromium.org/11266011
      Patch from Adam Klein <adamk@chromium.org>.
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c203f054
  26. 06 Nov, 2012 1 commit
  27. 05 Nov, 2012 1 commit
    • svenpanne@chromium.org's avatar
      Heavy cleanup of the external pointer API. · f3807ca1
      svenpanne@chromium.org authored
      Added highly efficient Object::SetAlignedPointerInInternalField and
      Object::GetAlignedPointerFromInternalField functions for 2-byte-aligned
      pointers. Their non-aligned counterparts Object::GetPointerFromInternalField and
      Object::SetPointerInInternalField are now deprecated utility functions.
      
      External is now a true Value again, with New/Value/Cast using a JSObject with an
      internal field containing a Foreign. External::Wrap, and External::Unwrap are now
      deprecated utility functions.
      
      Added Context::GetEmbedderData and Context::SetEmbedderData. Deprecated
      Context::GetData and Context::SetData, these are now only wrappers to access
      internal field 0.
      
      Added highly efficient Context::SetAlignedPointerInEmbedderData and
      Context::GetAlignedPointerFromEmbedderData functions for 2-byte-aligned
      pointers.
      
      Review URL: https://codereview.chromium.org/11190050
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f3807ca1
  28. 17 Sep, 2012 1 commit
  29. 27 Aug, 2012 1 commit
  30. 17 Aug, 2012 2 commits
  31. 09 Jul, 2012 1 commit
    • rossberg@chromium.org's avatar
      Implement proper module linking. · 98db1a36
      rossberg@chromium.org authored
      Specifically:
      
      - In parser, check that all exports are defined.
      - Move JSModule allocation from parser to scope resolution.
      - Move JSModule linking from full codegen to scope resolution.
      - Implement module accessors for exported value members.
      - Allocate module contexts statically along with JSModules
        (to allow static linking), but chain them when module literal is evaluated.
      - Make module contexts' extension slot refer to resp. JSModule
        (makes modules' ScopeInfo accessible from context).
      - Some other tweaks to context handling in general.
      - Make any code containing module literals (and thus embedding
        static references to JSModules) non-cacheable.
      
      This enables accessing module instance objects as expected.
      Import declarations are a separate feature and do not work yet.
      
      R=mstarzinger@chromium.org
      BUG=v8:1569
      TEST=
      
      Review URL: https://chromiumcodereview.appspot.com/10690043
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      98db1a36
  32. 23 May, 2012 1 commit
  33. 16 Apr, 2012 1 commit
  34. 20 Feb, 2012 1 commit
  35. 02 Feb, 2012 1 commit
  36. 26 Jan, 2012 1 commit
  37. 27 Dec, 2011 1 commit