Skip to content

V
V8
Switch branch/tag
  1. 29 May, 2013 1 commit
  3. 23 Apr, 2013 1 commit
  5. 10 Apr, 2013 2 commits
  7. 22 Mar, 2013 2 commits
  9. 13 Mar, 2013 1 commit
  11. 25 Feb, 2013 1 commit
  13. 15 Feb, 2013 1 commit
  15. 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
  17. 03 Jan, 2013 1 commit
  19. 22 Nov, 2012 1 commit
  21. 16 Nov, 2012 1 commit
  23. 12 Nov, 2012 1 commit
  25. 06 Nov, 2012 1 commit
  27. 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
  29. 19 Jul, 2012 1 commit
  31. 18 Jul, 2012 1 commit
  33. 10 Jul, 2012 1 commit
  35. 06 Jul, 2012 1 commit
  37. 28 Jun, 2012 1 commit
  39. 27 Jun, 2012 1 commit
  41. 12 Mar, 2012 1 commit
  43. 05 Jan, 2012 1 commit
  45. 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
  47. 09 Nov, 2011 1 commit
  49. 25 Oct, 2011 1 commit
  51. 24 Oct, 2011 1 commit
  53. 19 Oct, 2011 2 commits
  55. 18 Oct, 2011 1 commit
  57. 05 Oct, 2011 1 commit
  59. 04 Oct, 2011 1 commit
  61. 26 Sep, 2011 1 commit
  63. 22 Sep, 2011 1 commit
  65. 13 Sep, 2011 1 commit
  67. 28 Jul, 2011 1 commit
  69. 13 Jul, 2011 1 commit
  71. 12 Jul, 2011 1 commit
  73. 30 Jun, 2011 1 commit