1. 05 Feb, 2016 2 commits
    • cbruni's avatar
      [telemetry] Counter Cleanups · d037e6d6
      cbruni authored
      - remove unused counters
      - add "ic" prefix to all ic-counters
      - add more counter: maps-created, global deopts (not used yet)
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1553523002
      
      Cr-Commit-Position: refs/heads/master@{#33768}
      d037e6d6
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
      
      Reason for revert:
      Must revert for now due to chromium api natives issues.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > (RELAND: the problem before was a missing write barrier for adding the code
      > entry to the new closure. It's been addressed with a new macro instruction
      > and test. The only change to this CL is the addition of two calls to
      > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      > And Benedikt reviewed it as well.
      >
      > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
      > Cr-Commit-Position: refs/heads/master@{#33741}
      
      TBR=bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1670813005
      
      Cr-Commit-Position: refs/heads/master@{#33766}
      3f36e658
  2. 04 Feb, 2016 3 commits
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored
      (RELAND: the problem before was a missing write barrier for adding the code
      entry to the new closure. It's been addressed with a new macro instruction
      and test. The only change to this CL is the addition of two calls to
      __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      And Benedikt reviewed it as well.
      
      TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1668103002
      
      Cr-Commit-Position: refs/heads/master@{#33741}
      bb31db3a
    • yangguo's avatar
      [interpreter] do not serialize bytecode for snapshot. · 34645da5
      yangguo authored
      Code compiled during snapshot are overwhelmingly for functions
      that are only used for bootstrapping. It makes no sense to
      include them in the startup snapshot, which bloats up the snapshot size
      and slows down deserialization.
      
      Snapshot sizes for comparison, for ia32:
      w/o --ignition:   484k
      w/ --ignition:    537k
      bytecode removed: 489k
      
      R=rmcilroy@chromium.org,mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1667693002
      
      Cr-Commit-Position: refs/heads/master@{#33734}
      34645da5
    • mvstanton's avatar
      Write barrier for storing a code entry, and usage in CompileLazy builtin. · 477e1336
      mvstanton authored
      BUG=
      
      Review URL: https://codereview.chromium.org/1647123002
      
      Cr-Commit-Position: refs/heads/master@{#33718}
      477e1336
  3. 03 Feb, 2016 2 commits
  4. 02 Feb, 2016 2 commits
  5. 29 Jan, 2016 1 commit
    • jkummerow's avatar
      Introduce {FAST,SLOW}_STRING_WRAPPER_ELEMENTS · f4872f74
      jkummerow authored
      String wrappers (new String("foo")) are special objects: their string
      characters are accessed like elements, and they also have an elements
      backing store. This used to require a bunch of explicit checks like:
      
      if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
        /* Handle string characters */
      }
      // Handle regular elements (for string wrappers and other objects)
      obj->GetElementsAccessor()->Whatever(...);
      
      This CL introduces new ElementsKinds for string wrapper objects (one for
      fast elements, one for dictionary elements), which allow folding the
      special-casing into new StringWrapperElementsAccessors.
      
      No observable change in behavior is intended.
      
      Review URL: https://codereview.chromium.org/1612323003
      
      Cr-Commit-Position: refs/heads/master@{#33616}
      f4872f74
  6. 28 Jan, 2016 3 commits
  7. 27 Jan, 2016 4 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
      
      Reason for revert:
      Bug: failing to use write barrier when writing code entry into closure.
      
      Original issue's description:
      > Reland of Type Feedback Vector lives in the closure
      >
      > (Fixed a bug found by nosnap builds.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      > BUG=
      >
      > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
      > Cr-Commit-Position: refs/heads/master@{#33548}
      
      TBR=bmeurer@chromium.org,yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1643533003
      
      Cr-Commit-Position: refs/heads/master@{#33556}
      a7027851
    • mlippautz's avatar
      Reland of "[heap] Parallel newspace evacuation, semispace copy, and compaction \o/" · 004ce08d
      mlippautz authored
      This reverts commit 85ba94f2.
      
      All parallelism can be turned off using --predictable, or --noparallel-compaction.
      
      This patch completely parallelizes
       - semispace copy: from space -> to space (within newspace)
       - newspace evacuation: newspace -> oldspace
       - oldspace compaction: oldspace -> oldspace
      
      Previously newspace has been handled sequentially (semispace copy, newspace
      evacuation) before compacting oldspace in parallel. However, on a high level
      there are no dependencies between those two actions, hence we parallelize them
      altogether. We base the number of evacuation tasks on the overall set of
      to-be-processed pages (newspace + oldspace compaction pages).
      
      Some low-level details:
       - The hard cap on number of tasks has been lifted
       - We cache store buffer entries locally before merging them back into the global
         StoreBuffer in a finalization phase.
       - We cache AllocationSite operations locally before merging them back into the
         global pretenuring storage in a finalization phase.
       - AllocationSite might be compacted while they would be needed for newspace
         evacuation. To mitigate any problems we defer checking allocation sites for
         newspace till merging locally buffered data.
      
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
      BUG=chromium:524425
      LOG=N
      R=hpayer@chromium.org, ulan@chromium.org
      
      Review URL: https://codereview.chromium.org/1640563004
      
      Cr-Commit-Position: refs/heads/master@{#33552}
      004ce08d
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      mvstanton authored
      (Fixed a bug found by nosnap builds.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1642613002
      
      Cr-Commit-Position: refs/heads/master@{#33548}
      d984b3b0
    • machenbach's avatar
      Revert of [heap] Parallel newspace evacuation, semispace copy, and compaction... · 85ba94f2
      machenbach authored
      Revert of [heap] Parallel newspace evacuation, semispace copy, and compaction \o/ (patchset #16 id:620001 of https://codereview.chromium.org/1577853007/ )
      
      Reason for revert:
      [Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
      https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664
      
      Original issue's description:
      > [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
      >
      > All parallelism can be turned off using --predictable, or --noparallel-compaction.
      >
      > This patch completely parallelizes
      >  - semispace copy: from space -> to space (within newspace)
      >  - newspace evacuation: newspace -> oldspace
      >  - oldspace compaction: oldspace -> oldspace
      >
      > Previously newspace has been handled sequentially (semispace copy, newspace
      > evacuation) before compacting oldspace in parallel. However, on a high level
      > there are no dependencies between those two actions, hence we parallelize them
      > altogether. We base the number of evacuation tasks on the overall set of
      > to-be-processed pages (newspace + oldspace compaction pages).
      >
      > Some low-level details:
      >  - The hard cap on number of tasks has been lifted
      >  - We cache store buffer entries locally before merging them back into the global
      >    StoreBuffer in a finalization phase.
      >  - We cache AllocationSite operations locally before merging them back into the
      >    global pretenuring storage in a finalization phase.
      >  - AllocationSite might be compacted while they would be needed for newspace
      >    evacuation. To mitigate any problems we defer checking allocation sites for
      >    newspace till merging locally buffered data.
      >
      > CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
      > BUG=chromium:524425
      > LOG=N
      > R=hpayer@chromium.org, ulan@chromium.org
      >
      > Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
      > Cr-Commit-Position: refs/heads/master@{#33523}
      
      TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:524425
      
      Review URL: https://codereview.chromium.org/1643473002
      
      Cr-Commit-Position: refs/heads/master@{#33539}
      85ba94f2
  8. 26 Jan, 2016 5 commits
    • mlippautz's avatar
      [heap] Parallel newspace evacuation, semispace copy, and compaction \o/ · 8f0fd8c0
      mlippautz authored
      All parallelism can be turned off using --predictable, or --noparallel-compaction.
      
      This patch completely parallelizes
       - semispace copy: from space -> to space (within newspace)
       - newspace evacuation: newspace -> oldspace
       - oldspace compaction: oldspace -> oldspace
      
      Previously newspace has been handled sequentially (semispace copy, newspace
      evacuation) before compacting oldspace in parallel. However, on a high level
      there are no dependencies between those two actions, hence we parallelize them
      altogether. We base the number of evacuation tasks on the overall set of
      to-be-processed pages (newspace + oldspace compaction pages).
      
      Some low-level details:
       - The hard cap on number of tasks has been lifted
       - We cache store buffer entries locally before merging them back into the global
         StoreBuffer in a finalization phase.
       - We cache AllocationSite operations locally before merging them back into the
         global pretenuring storage in a finalization phase.
       - AllocationSite might be compacted while they would be needed for newspace
         evacuation. To mitigate any problems we defer checking allocation sites for
         newspace till merging locally buffered data.
      
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
      BUG=chromium:524425
      LOG=N
      R=hpayer@chromium.org, ulan@chromium.org
      
      Review URL: https://codereview.chromium.org/1577853007
      
      Cr-Commit-Position: refs/heads/master@{#33523}
      8f0fd8c0
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
      
      Reason for revert:
      FAilure on win32 bot, need to investigate webkit failures.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
      > Cr-Commit-Position: refs/heads/master@{#33518}
      
      TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1632993003
      
      Cr-Commit-Position: refs/heads/master@{#33520}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1563213002
      
      Cr-Commit-Position: refs/heads/master@{#33518}
      a5200f7e
    • mlippautz's avatar
      [heap] Cleanup SemiSpace · 8391d425
      mlippautz authored
      - Remove semispace target capacity: It's unused and adds some unneeded
        complexity
      
      - Enforcing decl order for SemiSpace
      - Move forward declarations in spaces.h to top
      - Add all members to default constructor
      
      BUG=chromium:581076
      LOG=N
      
      Review URL: https://codereview.chromium.org/1631713002
      
      Cr-Commit-Position: refs/heads/master@{#33515}
      8391d425
    • mlippautz's avatar
      [heap] Move symbols and internalized strings to global header · 51879692
      mlippautz authored
      BUG=
      R=hpayer@chromium.org
      
      Review URL: https://codereview.chromium.org/1634513002
      
      Cr-Commit-Position: refs/heads/master@{#33506}
      51879692
  9. 25 Jan, 2016 1 commit
    • mlippautz's avatar
      [heap] Cleanup: Remove WAS_SWEPT flag. · 5eff5420
      mlippautz authored
      - Completely rely on the concurrent sweeping state for SweepingCompleted()
      - Rename the state accordingly.
      
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
      R=hpayer@chromium.org
      
      Review URL: https://codereview.chromium.org/1614953002
      
      Cr-Commit-Position: refs/heads/master@{#33490}
      5eff5420
  10. 22 Jan, 2016 2 commits
  11. 21 Jan, 2016 3 commits
  12. 20 Jan, 2016 1 commit
  13. 19 Jan, 2016 1 commit
  14. 18 Jan, 2016 1 commit
  15. 15 Jan, 2016 4 commits
  16. 14 Jan, 2016 1 commit
  17. 12 Jan, 2016 2 commits
    • mlippautz's avatar
      [heap, deoptimizer] Use proper right trim instead of manually trimming · 8cf79873
      mlippautz authored
      Failing to do so results in out-of-date marking information, because live bytes
      is not properly adjusted.
      
      This CL adds support for right trimming ByteArray and properly DCHECKs that we
      do not left trim  ByteArray (as we already do for FixedTypedArrayBase).
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1577263003
      
      Cr-Commit-Position: refs/heads/master@{#33252}
      8cf79873
    • mlippautz's avatar
      [heap] Use HashMap as scratchpad backing store · 55422bdd
      mlippautz authored
      We use a scratchpad to remember visited allocation sites for post processing
      (making tenure decisions). The previous implementation used a rooted FixedArray
      with constant length (256) to remember all sites. Updating the scratchpad is a
      bottleneck in any parallel/concurrent implementation of newspace evacuation.
      
      The new implementation uses a HashMap with allocation sites as keys and
      temporary counts as values. During evacuation we collect a local hashmap of
      visited allocation sites. Upon merging the local hashmap back into a global one
      we update potential forward pointers of compacted allocation sites.  The
      scavenger can directly enter its entries into the global hashmap. Note that the
      actual memento found count is still kept on the AllocationSite as it needs to
      survive scavenges and full GCs.
      
      BUG=chromium:524425
      LOG=N
      R=hpayer@chromium.org
      
      Review URL: https://codereview.chromium.org/1535723002
      
      Cr-Commit-Position: refs/heads/master@{#33233}
      55422bdd
  18. 11 Jan, 2016 2 commits