Skip to content

V
V8
Switch branch/tag
  1. 07 Dec, 2012 1 commit
  3. 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
  5. 13 Nov, 2012 1 commit
  7. 09 Nov, 2012 1 commit
  9. 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
  11. 06 Nov, 2012 1 commit
  13. 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
  15. 17 Sep, 2012 1 commit
  17. 27 Aug, 2012 1 commit
  19. 17 Aug, 2012 2 commits
  21. 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
  23. 23 May, 2012 1 commit
  25. 16 Apr, 2012 1 commit
  27. 20 Feb, 2012 1 commit
  29. 02 Feb, 2012 1 commit
  31. 26 Jan, 2012 1 commit
  33. 27 Dec, 2011 1 commit
  35. 15 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Static resolution of outer variables in eval code. · 08c9629f
      keuchel@chromium.org authored 
      So far free variables references in eval code are not statically
resolved. For example in
    function foo() { var x = 1; eval("y = x"); }
the variable x will get mode DYNAMIC and y will get mode DYNAMIC_GLOBAL,
i.e. free variable references trigger dynamic lookups with a fast case
handling for global variables.

The CL introduces static resolution of free variables references in eval
code. If possible variable references are resolved to bindings belonging to
outer scopes of the eval call site.

This is achieved by deserializing the outer scope chain using
Scope::DeserializeScopeChain prior to parsing the eval code similar to lazy
parsing of functions. The existing code for variable resolution is used,
however resolution starts at the first outer unresolved scope instead of
always starting at the root of the scope tree.

This is a prerequisite for statically checking validity of assignments in
the extended code as specified by the current ES.next draft which will be
introduced by a subsequent CL. More specifically section 11.13 of revision 4
of the ES.next draft reads:
* It is a Syntax Error if the AssignmentExpression is contained in extended
  code and the LeftHandSideExpression is an Identifier that does not
  statically resolve to a declarative environment record binding or if the
  resolved binding is an immutable binding.

TEST=existing tests in mjsunit

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9999 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      08c9629f
  37. 25 Oct, 2011 1 commit
  39. 24 Oct, 2011 2 commits
  41. 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
  43. 19 Oct, 2011 1 commit
  45. 18 Oct, 2011 1 commit
  47. 17 Oct, 2011 1 commit
  49. 21 Sep, 2011 2 commits
  51. 13 Sep, 2011 1 commit
  53. 12 Sep, 2011 3 commits
  55. 30 Aug, 2011 1 commit
  57. 11 Aug, 2011 1 commit
  59. 19 Jul, 2011 1 commit
  61. 01 Jul, 2011 1 commit
  63. 28 Jun, 2011 1 commit
  65. 16 Jun, 2011 2 commits
  67. 15 Jun, 2011 1 commit