Skip to content

V
V8
Switch branch/tag
  1. 04 Jan, 2013 1 commit
  3. 18 Dec, 2012 1 commit
  5. 10 Dec, 2012 1 commit
  7. 07 Dec, 2012 1 commit
  9. 05 Dec, 2012 1 commit
  11. 03 Dec, 2012 2 commits
  13. 30 Nov, 2012 2 commits
  15. 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
  17. 06 Aug, 2012 1 commit
  19. 31 Jul, 2012 1 commit
  21. 25 Jul, 2012 2 commits
  23. 20 Jun, 2012 1 commit
  25. 11 Jun, 2012 4 commits
  27. 04 Jun, 2012 1 commit
  29. 16 Apr, 2012 3 commits
  31. 27 Mar, 2012 1 commit
  33. 15 Mar, 2012 1 commit
    • svenpanne@chromium.org's avatar
      Ensure that generated code for object literals will call... · c644c4e8
      svenpanne@chromium.org authored 
      Ensure that generated code for object literals will call Runtime_DefineOrRedefineAccessorProperty only once per accessor property.

To do this, we collect all accessor properties in a first pass and emit code for
defining those properties afterwards in a second pass.

As a finger exercise, the table used for collecting accessors has a (subset of
an) STL-like iterator interface, including STL-like names and operators.
Although C++ is quite verbose here (as usual, but partly this is caused by our
current slightly clumsy classes/templates), things work out quite nicely and it
cleans up some confusion, e.g. a table entry is not an iterator etc.
Everything compiles into very efficient code, e.g. the loop condition 'it !=
accessor_table.end()' compiles into a single 'testl' instruction on ia32.
+1 for using standard APIs!

Review URL: https://chromiumcodereview.appspot.com/9691040

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c644c4e8
  35. 09 Mar, 2012 1 commit
  37. 27 Feb, 2012 1 commit
  39. 22 Feb, 2012 1 commit
    • vegorov@chromium.org's avatar
      Support fast case for-in in Crankshaft. · 6703ddda
      vegorov@chromium.org authored 
      Only JSObject enumerables with enum cache (fast case properties, no interceptors, no enumerable properties on the prototype) are supported.

HLoadKeyedGeneric with keys produced by for-in enumeration are recognized and rewritten into direct property load by index. For this enum-cache was extended to store property indices in a separate array (see handles.cc).

New hydrogen instructions:

- HForInPrepareMap: checks for-in fast case preconditions and returns map that contains enum-cache;
- HForInCacheArray: extracts enum-cache array from the map;
- HCheckMapValue: map check with HValue map instead of immediate;
- HLoadFieldByIndex: load fast property by it's index, positive indexes denote in-object properties, negative - out of object properties;

Changed hydrogen instructions:

- HLoadKeyedFastElement: added hole check suppression for loads from internal FixedArrays that are knows to have no holes inside.

R=fschneider@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9425045

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      6703ddda
  41. 20 Feb, 2012 1 commit
  43. 14 Feb, 2012 2 commits
  45. 09 Feb, 2012 1 commit
  47. 27 Jan, 2012 1 commit
  49. 20 Jan, 2012 1 commit
  51. 16 Jan, 2012 1 commit
  53. 30 Nov, 2011 1 commit
  55. 24 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Introduce extended mode. · 1e9a7267
      keuchel@chromium.org authored 
      This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.

The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.

This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
  ResolvePossiblyDirectEval, InitializeVarGlobal,
  DeclareGlobals

The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache

Review URL: http://codereview.chromium.org/8417035

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1e9a7267
  57. 11 Nov, 2011 3 commits