Skip to content

V
V8
Switch branch/tag
  1. 16 Apr, 2012 1 commit
    • rossberg@chromium.org's avatar
      Implement rudimentary module linking. · ab26fb6b
      rossberg@chromium.org authored 
      Constructs the (generally cyclic) graph of module instance objects
and populates their exports. Any exports other than nested modules
are currently set to 'undefined' (but already present as properties).

Details:
- Added new type JSModule for instance objects: a JSObject carrying a context.
- Statically allocate instance objects for all module literals (in parser 8-}).
- Extend interfaces to record and unify concrete instance objects,
  and to support iteration over members.
- Introduce new runtime function for pushing module contexts.
- Generate code for allocating, initializing, and setting module contexts,
  and for populating instance objects from module literals.
  Currently, all non-module exports are still initialized with 'undefined'.
- Module aliases are resolved statically, so no special code is required.
- Make sure that code containing module constructs is never optimized
  (macrofy AST node construction flag setting while we're at it).
- Add test case checking linkage.

Baseline: http://codereview.chromium.org/9722043/

R=svenpanne@chromium.org,mstarzinger@chromium.org
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ab26fb6b
  3. 23 Mar, 2012 1 commit
  5. 19 Mar, 2012 1 commit
  7. 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
  9. 13 Mar, 2012 1 commit
  11. 09 Mar, 2012 1 commit
  13. 08 Mar, 2012 1 commit
  15. 29 Feb, 2012 1 commit
  17. 28 Feb, 2012 3 commits
  19. 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
  21. 20 Feb, 2012 1 commit
  23. 14 Feb, 2012 1 commit
  25. 10 Feb, 2012 1 commit
  27. 09 Feb, 2012 4 commits
  29. 08 Feb, 2012 1 commit
  31. 25 Jan, 2012 1 commit
  33. 05 Dec, 2011 1 commit
  35. 29 Nov, 2011 1 commit
  37. 28 Nov, 2011 2 commits
  39. 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
  41. 18 Nov, 2011 1 commit
  43. 17 Nov, 2011 1 commit
  45. 11 Nov, 2011 3 commits
  47. 09 Nov, 2011 2 commits
  49. 08 Nov, 2011 2 commits
  51. 02 Nov, 2011 1 commit
  53. 31 Oct, 2011 1 commit
  55. 25 Oct, 2011 1 commit
  57. 24 Oct, 2011 1 commit
  59. 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