1. 15 Feb, 2016 1 commit
  2. 09 Feb, 2016 1 commit
  3. 05 Feb, 2016 1 commit
    • 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
  4. 04 Feb, 2016 2 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
  5. 27 Jan, 2016 2 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
    • 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
  6. 26 Jan, 2016 2 commits
    • 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
  7. 18 Jan, 2016 1 commit
    • mstarzinger's avatar
      Drop "current_code" from compiler API. · 8041a753
      mstarzinger authored
      This removes the need to pass in the current unoptimized code when
      requesting optimized code for a function. Note that the notion of
      unoptimized code becomes moot when optimizing from the interpreter
      bytecode, hence the API should not encode such a dependency.
      
      R=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1588293005
      
      Cr-Commit-Position: refs/heads/master@{#33353}
      8041a753
  8. 11 Jan, 2016 1 commit
  9. 22 Dec, 2015 1 commit
  10. 18 Nov, 2015 1 commit
  11. 12 Oct, 2015 2 commits
  12. 04 Sep, 2015 1 commit
  13. 01 Sep, 2015 1 commit
  14. 18 Aug, 2015 2 commits
  15. 17 Aug, 2015 1 commit
  16. 12 Aug, 2015 1 commit
  17. 24 Jul, 2015 1 commit
  18. 07 Jul, 2015 1 commit
  19. 06 Jul, 2015 3 commits
    • bmeurer's avatar
      [turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR... · ef661b08
      bmeurer authored
      [turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early and remove type propagation.".
      
      We have to reland these two commits at once, because the first breaks
      some asm.js benchmarks without the second. The change was reverted
      because of bogus checks in the verifier, which will not work in the
      presence of OSR (and where hidden because of the type back propagation
      hack in OSR so far). Original messages are below:
      
      [turbofan] Add new JSFrameSpecialization reducer.
      
      The JSFrameSpecialization specializes an OSR graph to the current
      unoptimized frame on which we will perform the on-stack replacement.
      This is used for asm.js functions, where we cannot reuse the OSR
      code object anyway because of context specialization, and so we could as
      well specialize to the max instead.
      
      It works by replacing all OsrValues in the graph with their values
      in the JavaScriptFrame.
      
      The idea is that using this trick we get better performance without
      doing the unsound backpropagation of types to OsrValues later. This
      is the first step towards fixing OSR for TurboFan.
      
      [turbofan] Perform OSR deconstruction early and remove type propagation.
      
      This way we don't have to deal with dead pre-OSR code in the graph
      and risk optimizing the wrong code, especially we don't make
      optimistic assumptions in the dead code that leaks into the OSR code
      (i.e. deopt guards are in dead code, but the types propagate to OSR
      code via the OsrValue type back propagation).
      
      BUG=v8:4273
      LOG=n
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1226673005
      
      Cr-Commit-Position: refs/heads/master@{#29486}
      ef661b08
    • machenbach's avatar
      Revert "[turbofan] Add new JSFrameSpecialization reducer." · 9e71cdba
      machenbach authored
      Also revert "[turbofan] Perform OSR deconstruction early and remove type propagation."
      
      This reverts commit b0a852e8.
      
      This reverts commit cdbb6c48.
      
      NOTRY=true
      NOTREECHECKS=true
      BUG=v8:4273
      LOG=n
      TBR=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1225743002
      
      Cr-Commit-Position: refs/heads/master@{#29480}
      9e71cdba
    • bmeurer's avatar
      [turbofan] Add new JSFrameSpecialization reducer. · b0a852e8
      bmeurer authored
      The JSFrameSpecialization specializes an OSR graph to the current
      unoptimized frame on which we will perform the on-stack replacement.
      This is used for asm.js functions, where we cannot reuse the OSR code
      object anyway because of context specialization, and so we could as well
      specialize to the max instead.
      
      It works by replacing all OsrValues in the graph with their values in
      the JavaScriptFrame.
      
      The idea is that using this trick we get better performance without
      doing the unsound backpropagation of types to OsrValues later. This is
      the first step towards fixing OSR for TurboFan.
      
      R=jarin@chromium.org
      BUG=v8:4273
      LOG=n
      
      Review URL: https://codereview.chromium.org/1225683004
      
      Cr-Commit-Position: refs/heads/master@{#29476}
      b0a852e8
  20. 12 Jun, 2015 5 commits
  21. 20 May, 2015 2 commits
  22. 21 Apr, 2015 1 commit
  23. 17 Apr, 2015 1 commit
  24. 16 Apr, 2015 2 commits
  25. 14 Apr, 2015 3 commits