1. 15 Jul, 2015 2 commits
    • mvstanton's avatar
      Special printing for type feedback vectors. · 9386b861
      mvstanton authored
      Gdb macro jfv on an object will print it as a feedback vector.
      Printouts look like this:
      
      DebugPrint: 0x5dc0d2ad: [TypeFeedbackVector]
       - length: 12
       - ics with type info: 3
       - generic ics: 0
       ICSlot 0 CALL_IC MONOMORPHIC
        [4]: 0x5dc0d365 WeakCell for 0x5dc0cd69 <JS Function foo (SharedFunctionInfo 0x5dc0cb0d)>
        [5]: 0x4203c4c1 <Code: HANDLER>
       ICSlot 1 LOAD_IC MONOMORPHIC
        [6]: 0x5dc0d1f5 WeakCell for 0x3a710481 <Map(FAST_HOLEY_SMI_ELEMENTS)>
        [7]: 0x4203a1c1 <Code: HANDLER>
       ICSlot 2 LOAD_IC UNINITIALIZED
        [8]: 0x3060d045 <Symbol: 711234650 <String[20]: uninitialized_symbol>>
        [9]: 0x3060d045 <Symbol: 711234650 <String[20]: uninitialized_symbol>>
       ICSlot 3 LOAD_IC MONOMORPHIC
        [10]: 0x5dc0d3b5 WeakCell for 0x3a710d71 <Map(FAST_HOLEY_ELEMENTS)>
        [11]: 0x4202af01 <Code: HANDLER>
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1225403005
      
      Cr-Commit-Position: refs/heads/master@{#29679}
      9386b861
    • yangguo's avatar
      Debugger: use debug break slots to break at function exit. · fc9c5275
      yangguo authored
      By not having to patch the return sequence (we patch the debug
      break slot right before it), we don't overwrite it and therefore
      don't have to keep the original copy of the code around.
      
      R=ulan@chromium.org
      BUG=v8:4269
      LOG=N
      
      Review URL: https://codereview.chromium.org/1234833003
      
      Cr-Commit-Position: refs/heads/master@{#29672}
      fc9c5275
  2. 13 Jul, 2015 2 commits
  3. 02 Jul, 2015 2 commits
  4. 25 Jun, 2015 3 commits
  5. 23 Jun, 2015 2 commits
  6. 19 Jun, 2015 1 commit
    • yangguo's avatar
      Keep a canonical list of shared function infos. · c1669450
      yangguo authored
      Each Script object now keeps a WeakFixedArray of SharedFunctionInfo
      objects created from this script.
      
      This way, when compiling a function, we do not create duplicate shared
      function info objects when recompiling with either compiler.
      
      This fixes a class of issues in the debugger, where we set break points
      on one shared function info, but functions from duplicate shared function
      infos are not affected.
      
      LOG=N
      BUG=v8:4132
      
      Review URL: https://codereview.chromium.org/1183733006
      
      Cr-Commit-Position: refs/heads/master@{#29151}
      c1669450
  7. 16 Jun, 2015 1 commit
  8. 05 Jun, 2015 1 commit
  9. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1162993006
      
      Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  10. 03 Jun, 2015 2 commits
  11. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1131783003
      
      Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  12. 01 Jun, 2015 2 commits
  13. 18 May, 2015 1 commit
  14. 07 May, 2015 1 commit
  15. 29 Apr, 2015 1 commit
  16. 21 Apr, 2015 4 commits
    • jochen's avatar
      Revert of Reland "LayoutDescriptor should inherit from JSTypedArray" (patchset... · 1692380f
      jochen authored
      Revert of Reland "LayoutDescriptor should inherit from JSTypedArray" (patchset #3 id:40001 of https://codereview.chromium.org/1094333002/)
      
      Reason for revert:
      Breaks gbemu
      
      Original issue's description:
      > Reland "LayoutDescriptor should inherit from JSTypedArray"
      >
      > Original issue's description:
      > > LayoutDescriptor should inherit from JSTypedArray
      > >
      > > It can't just inherit from a FixedTypedArray-like type, as we soon
      > > assume that a FixedTypedArray-like type is always held by an
      > > ArrayBufferView-like type
      > >
      > > BUG=v8:3996
      > > R=ishell@chromium.org,verwaest@chromium.org
      > > LOG=n
      >
      > BUG=v8:3996
      > R=ishell@chromium.org,verwaest@chromium.org
      > LOG=n
      
      TBR=ishell@chromium.org,verwaest@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:3996
      
      Review URL: https://codereview.chromium.org/1080403004
      
      Cr-Commit-Position: refs/heads/master@{#27975}
      1692380f
    • jochen's avatar
      Reland "LayoutDescriptor should inherit from JSTypedArray" · d20660e0
      jochen authored
      Original issue's description:
      > LayoutDescriptor should inherit from JSTypedArray
      >
      > It can't just inherit from a FixedTypedArray-like type, as we soon
      > assume that a FixedTypedArray-like type is always held by an
      > ArrayBufferView-like type
      >
      > BUG=v8:3996
      > R=ishell@chromium.org,verwaest@chromium.org
      > LOG=n
      
      BUG=v8:3996
      R=ishell@chromium.org,verwaest@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1094333002
      
      Cr-Commit-Position: refs/heads/master@{#27973}
      d20660e0
    • jochen's avatar
      Revert of LayoutDescriptor should inherit from JSTypedArray (patchset #1 id:1... · 8a309a1e
      jochen authored
      Revert of LayoutDescriptor should inherit from JSTypedArray (patchset #1 id:1 of https://codereview.chromium.org/1084793004/)
      
      Reason for revert:
      breaks mjsunit on debug bots
      
      Original issue's description:
      > LayoutDescriptor should inherit from JSTypedArray
      >
      > It can't just inherit from a FixedTypedArray-like type, as we soon
      > assume that a FixedTypedArray-like type is always held by an
      > ArrayBufferView-like type
      >
      > BUG=v8:3996
      > R=ishell@chromium.org,verwaest@chromium.org
      > LOG=n
      
      TBR=ishell@chromium.org,verwaest@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:3996
      
      Review URL: https://codereview.chromium.org/1073053006
      
      Cr-Commit-Position: refs/heads/master@{#27968}
      8a309a1e
    • jochen's avatar
      LayoutDescriptor should inherit from JSTypedArray · 6d79ceb2
      jochen authored
      It can't just inherit from a FixedTypedArray-like type, as we soon
      assume that a FixedTypedArray-like type is always held by an
      ArrayBufferView-like type
      
      BUG=v8:3996
      R=ishell@chromium.org,verwaest@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1084793004
      
      Cr-Commit-Position: refs/heads/master@{#27964}
      6d79ceb2
  17. 07 Apr, 2015 1 commit
  18. 06 Mar, 2015 1 commit
  19. 05 Mar, 2015 2 commits
    • jkummerow's avatar
      Revert of Simplify and compact transitions storage (patchset #4 id:80001 of... · 948a973d
      jkummerow authored
      Revert of Simplify and compact transitions storage (patchset #4 id:80001 of https://codereview.chromium.org/980573002/)
      
      Reason for revert:
      x64 test failures
      
      Original issue's description:
      > Simplify and compact transitions storage
      >
      > Simple transitions are now stored in a map's "transitions" field (as a WeakCell wrapping the target map); full TransitionArrays are used when that's not sufficient.
      > To encapsulate these storage format implementation details, functions for manipulating and querying transitions have been refactored to be static functions on the TransitionArray class, and take maps as inputs.
      >
      > Committed: https://crrev.com/45fbef7f2252fce10634931cb103ccc1fc95ae6a
      > Cr-Commit-Position: refs/heads/master@{#27029}
      
      TBR=verwaest@chromium.org,ulan@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/982143002
      
      Cr-Commit-Position: refs/heads/master@{#27030}
      948a973d
    • jkummerow's avatar
      Simplify and compact transitions storage · 45fbef7f
      jkummerow authored
      Simple transitions are now stored in a map's "transitions" field (as a WeakCell wrapping the target map); full TransitionArrays are used when that's not sufficient.
      To encapsulate these storage format implementation details, functions for manipulating and querying transitions have been refactored to be static functions on the TransitionArray class, and take maps as inputs.
      
      Review URL: https://codereview.chromium.org/980573002
      
      Cr-Commit-Position: refs/heads/master@{#27029}
      45fbef7f
  20. 24 Feb, 2015 1 commit
  21. 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
  22. 23 Jan, 2015 1 commit
  23. 19 Jan, 2015 2 commits
  24. 07 Jan, 2015 1 commit
  25. 16 Dec, 2014 1 commit
  26. 12 Dec, 2014 1 commit
  27. 10 Dec, 2014 1 commit
    • adamk's avatar
      Optimize Object.seal and Object.preventExtensions · 4fa7ae1c
      adamk authored
      They both now run fast (due to utilizing transitions instead of always
      creating new maps) and sealed or non-extensible objects can stay in
      fast mode after transitioning.
      
      This almost entirely reuses the code for transitioning objects
      frozen by Object.freeze(), with the added benefit of freeing
      up a bit on the map (we no longer keep track of frozen-ness,
      as that bit wasn't used for anything interesting).
      
      BUG=v8:3662,chromium:115960
      LOG=y
      
      Review URL: https://codereview.chromium.org/776143005
      
      Cr-Commit-Position: refs/heads/master@{#25759}
      4fa7ae1c