1. 16 Feb, 2016 1 commit
  2. 01 Jun, 2015 1 commit
  3. 18 Feb, 2015 2 commits
  4. 16 Feb, 2015 1 commit
    • ishell's avatar
      Property reconfiguring implemented. · 35841b50
      ishell authored
      Previous approach for property reconfiguration was to create a free-floating map with generalized representations of all fields. This patch does it right.
      
      When property is reconfigured either by changing its kind (kData <-> kAccessor) or its attributes it implies creation of a new branch in transition tree. If such a branch already existed before reconfiguration then it should be merged with the old (or source) branch of the transition tree. Merging procedure includes all the heavy machinery such as property location changes (kDescriptor -> kField), field representation/field type generalization, map deprecation, etc.
      
      Review URL: https://codereview.chromium.org/888623002
      
      Cr-Commit-Position: refs/heads/master@{#26667}
      35841b50
  5. 19 Jan, 2015 1 commit
    • ishell's avatar
      Massive renaming of PropertyType values and other implied stuff. · 33994b4a
      ishell authored
      PropertyKind:
        DATA -> kData
        ACCESSOR -> kAccessor
      
      PropertyType:
        FIELD -> DATA
        CONSTANT -> DATA_CONSTANT
        ACCESSOR_FIELD -> ACCESSOR
        CALLBACKS -> ACCESSOR_CONSTANT
      
      PropertyLocation:
        IN_OBJECT -> kField
        IN_DESCRIPTOR -> kDescriptor
      
      StoreMode:
        FORCE_IN_OBJECT -> FORCE_FIELD
      
      FieldDescriptor -> DataDescriptor
      ConstantDescriptor -> DataConstantDescriptor
      CallbacksDescriptor -> AccessorConstantDescriptor
      
      Review URL: https://codereview.chromium.org/856503002
      
      Cr-Commit-Position: refs/heads/master@{#26146}
      33994b4a
  6. 16 Dec, 2014 1 commit
  7. 12 Dec, 2014 1 commit
  8. 24 Nov, 2014 1 commit
  9. 19 Nov, 2014 1 commit
  10. 23 Oct, 2014 1 commit
  11. 30 Sep, 2014 1 commit
  12. 08 Sep, 2014 1 commit
  13. 26 Aug, 2014 1 commit
  14. 21 Aug, 2014 1 commit
  15. 20 Aug, 2014 1 commit
  16. 30 Jul, 2014 1 commit
  17. 07 Jul, 2014 1 commit
  18. 03 Jul, 2014 1 commit
  19. 10 Jun, 2014 2 commits
  20. 06 Jun, 2014 1 commit
  21. 03 Jun, 2014 1 commit
  22. 15 Apr, 2014 1 commit
  23. 14 Apr, 2014 2 commits
  24. 04 Apr, 2014 1 commit
  25. 01 Apr, 2014 1 commit
  26. 18 Feb, 2014 1 commit
  27. 24 Jul, 2013 1 commit
  28. 07 May, 2013 1 commit
  29. 13 Nov, 2012 1 commit
  30. 27 Aug, 2012 1 commit
    • verwaest@chromium.org's avatar
      Make order of addition the primary order of descriptor arrays. · efb53e14
      verwaest@chromium.org authored
      The order by name is maintained as secondary order by using unused bits in the property details.
      
      This is preliminary work towards sharing descriptors arrays.
      
      The change allows us
      - to get rid of the LastAdded bits in the map, binding it to the number of valid descriptors for the given map
      - to avoid resorting by enumeration index to create the cache
      - (maybe in the future, depending on performance) to get rid of the enumeration cache altogether.
      
      Although generally the number_of_descriptors equals the NumberOfOwnDescriptors in the current version, this is preliminary work towards sharing    descriptors, where maps may have more descriptors than are valid for the map.
      
      Review URL: https://chromiumcodereview.appspot.com/10879013
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12385 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      efb53e14
  31. 05 Jul, 2012 1 commit
    • verwaest@chromium.org's avatar
      Separating transitions from descriptors. · d7a5b7d5
      verwaest@chromium.org authored
      In this design maps contain descriptor arrays, which in turn can contain transition arrays. If transitions are needed when no descriptor array is present, a descriptor array without real descriptors is inserted just so it can point at the transition array.
      
      The transition array does not contain details about the field it transitions to. In order to weed out transitions to FIELDs from CONSTANT_FUNCTION (what used to be MAP_TRANSITION vs CONSTANT_TRANSITION), the transition needs to be followed and the details need to be looked up in the target map. CALLBACKS transitions are still easy to recognize since the transition targets are stored as an AccessorPair containing the maps, rather than the maps directly.
      
      Currently AccessorPairs containing a transition and an accessor are shared between the descriptor array and the transition array. This simplifies lookup since we only have to look in one of both arrays. This will change in subsequent revisions, when descriptor arrays will become shared between multiple maps, since transitions cannot be shared.
      
      Review URL: https://chromiumcodereview.appspot.com/10697015
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d7a5b7d5
  32. 25 Jun, 2012 1 commit
  33. 11 Jun, 2012 1 commit
  34. 03 Feb, 2012 1 commit
    • svenpanne@chromium.org's avatar
      Removed IsTransitionType predicate. · b34e202b
      svenpanne@chromium.org authored
      With the upcoming changes to CALLBACKS properties, a predicate on the transition
      type alone doesn't make sense anymore: For CALLBACKS one has to look into the
      property's value to decide, and there is even the possibility of having a an
      accessor function *and* a transition in the same property.
      
      I am not completely happy with some parts of this CL, because they contain
      redundant code, but given the various representations we currently have for
      property type/value pairs, I can see no easy way around that. Perhaps one can
      improve this a bit in a different CL, the current diversity really, really hurts
      productivity...
      
      As a bonus, this CL includes a few minor things:
      
       * CaseClause::RecordTypeFeedback has been cleaned up and it handles the
         NULL_DESCRIPTOR case correctly now. Under some (very unlikely) circumstances,
         we previously missed some opportunities for monomorphic calls. In general, it
         is rather unfortunate that NULL_DESCRIPTOR "shines through", it is just a
         hack for the inability to remove a descriptor entry during GC, something
         callers shouldn't have to be aware of.
      
       * DescriptorArray::CopyInsert has been cleaned up a bit, preparing it for later
         CALLBACKS-related changes.
      
       * LookupResult::Print is now more informative for CONSTANT_TRANSITION.
      
      Review URL: https://chromiumcodereview.appspot.com/9320066
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10600 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      b34e202b
  35. 18 Oct, 2011 1 commit
  36. 09 Sep, 2011 1 commit
  37. 16 May, 2011 1 commit