Skip to content

V
V8
Switch branch/tag
  1. 23 Jan, 2013 1 commit
    • yangguo@chromium.org's avatar
      Avoid handle dereference during graph optimization. · 3c225241
      yangguo@chromium.org authored 
      With parallel recompilation enabled, objects made accessible by handles may
have changed between graph construction and graph optimization. Therefore
we must not assume that information on those objects remain the same between
those two phases. To police this, we forbid handle dereferencing during
graph optimization.
Exceptions to this rule are:
 - Dereferencing the handle to obtain the raw location of the object. This
   is safe since parallel recompilation acquires RelocationLock
 - Some places that dereference the handle for a type check. These are checked
   to be safe on a case-by-case basis.

R=jkummerow@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13475 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      3c225241
  3. 03 Jan, 2013 1 commit
  5. 22 Nov, 2012 1 commit
  7. 16 Nov, 2012 1 commit
  9. 12 Nov, 2012 1 commit
  11. 06 Nov, 2012 1 commit
  13. 12 Sep, 2012 1 commit
    • verwaest@chromium.org's avatar
      Sharing of descriptor arrays. · ebd3241b
      verwaest@chromium.org authored 
      This CL adds multiple things:
Transition arrays do not directly point at their descriptor array anymore, but rather do so via an indirect pointer (a JSGlobalPropertyCell).

An ownership bit is added to maps indicating whether it owns its own descriptor array or not.

Maps owning a descriptor array can pass on ownership if a transition from that map is generated; but only if the descriptor array stays exactly the same; or if a descriptor is added.

Maps that don't have ownership get ownership back if their direct child to which ownership was passed is cleared in ClearNonLiveTransitions.

To detect which descriptors in an array are valid, each map knows its own NumberOfOwnDescriptors. Since the descriptors are sorted in order of addition, if we search and find a descriptor with index bigger than this number, it is not valid for the given map.

We currently still build up an enumeration cache (although this may disappear). The enumeration cache is always built for the entire descriptor array, even if not all descriptors are owned by the map. Once a descriptor array has an enumeration cache for a given map; this invariant will always be true, even if the descriptor array was extended. The extended array will inherit the enumeration cache from the smaller descriptor array. If a map with more descriptors needs an enumeration cache, it's EnumLength will still be set to invalid, so it will have to recompute the enumeration cache. This new cache will also be valid for smaller maps since they have their own enumlength; and use this to loop over the cache. If the EnumLength is still invalid, but there is already a cache present that is big enough; we just initialize the EnumLength field for the map.

When we apply ClearNonLiveTransitions and descriptor ownership is passed back to a parent map, the descriptor array is trimmed in-place and resorted. At the same time, the enumeration cache is trimmed in-place.

Only transition arrays contain descriptor arrays. If we transition to a map and pass ownership of the descriptor array along, the child map will not store the descriptor array it owns. Rather its parent will keep the pointer. So for every leaf-map, we find the descriptor array by following the back pointer, reading out the transition array, and fetching the descriptor array from the JSGlobalPropertyCell. If a map has a transition array, we fetch it from there. If a map has undefined as its back-pointer and has no transition array; it is considered to have an empty descriptor array.

When we modify properties, we cannot share the descriptor array. To accommodate this, the child map will get its own transition array; even if there are not necessarily any transitions leaving from the child map. This is necessary since it's the only way to store its own descriptor array.

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ebd3241b
  15. 19 Jul, 2012 1 commit
  17. 18 Jul, 2012 1 commit
  19. 10 Jul, 2012 1 commit
  21. 06 Jul, 2012 1 commit
  23. 28 Jun, 2012 1 commit
  25. 27 Jun, 2012 1 commit
  27. 12 Mar, 2012 1 commit
  29. 05 Jan, 2012 1 commit
  31. 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
  33. 09 Nov, 2011 1 commit
  35. 25 Oct, 2011 1 commit
  37. 24 Oct, 2011 1 commit
  39. 19 Oct, 2011 2 commits
  41. 18 Oct, 2011 1 commit
  43. 05 Oct, 2011 1 commit
  45. 04 Oct, 2011 1 commit
  47. 26 Sep, 2011 1 commit
  49. 22 Sep, 2011 1 commit
  51. 13 Sep, 2011 1 commit
  53. 28 Jul, 2011 1 commit
  55. 13 Jul, 2011 1 commit
  57. 12 Jul, 2011 1 commit
  59. 30 Jun, 2011 1 commit
  61. 08 Jun, 2011 1 commit
  63. 31 May, 2011 1 commit
    • rossberg@chromium.org's avatar
      Implement set trap for proxies, and revamp class hierarchy in preparation: · 670f947a
      rossberg@chromium.org authored 
      - Introduce a class JSReceiver, that is a common superclass of JSObject and
  JSProxy. Use JSReceiver where appropriate (probably lots of places that we
  still have to migrate, but we will find those later with proxy test suite).

- Move appropriate methods to JSReceiver class (SetProperty,
  GetPropertyAttribute, Get/SetPrototype, Lookup, and so on).

- Introduce new JSFunctionProxy subclass of JSProxy. Currently only a stub.

- Overhaul enum InstanceType:
  * Introduce FIRST/LAST_SPEC_OBJECT_TYPE that ranges over all types that
    represent JS objects, and use that consistently to check language types.
  * Rename FIRST/LAST_JS_OBJECT_TYPE and FIRST/LAST_FUNCTION_CLASS_TYPE
    to FIRST/LAST_[NON]CALLABLE_SPEC_OBJECT_TYPE for clarity.
  * Eliminate the overlap over JS_REGEXP_TYPE.
  * Also replace FIRST_JS_OBJECT with FIRST_JS_RECEIVER, but only use it where
    we exclusively talk about the internal representation type.
  * Insert JS_PROXY and JS_FUNCTION_PROXY in the appropriate places.

- Fix all checks concerning classification, especially for functions, to
  use the CALLABLE_SPEC_OBJECT range (that includes funciton proxies).

- Handle proxies in SetProperty (that was the easiest part :) ).

- A few simple test cases.

R=kmillikin@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      670f947a
  65. 16 May, 2011 1 commit
  67. 06 May, 2011 1 commit
  69. 07 Apr, 2011 1 commit
  71. 21 Mar, 2011 1 commit
  73. 18 Mar, 2011 3 commits