1. 23 Sep, 2016 1 commit
  2. 10 Aug, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Switch profiler to use frames for OSR. · 685210ec
      mstarzinger authored
      This switches the interface of the runtime profiler to use frames as
      opposed to functions for performing on-stack replacement. Requests for
      such replacements need to target a specific frame. This will enable us
      to activate bytecode as well as baseline code for the same function.
      
      The existing %OptimizeOsr runtime function also had to adapted and now
      takes an optional stack depth to target a specific stack frame.
      
      R=bmeurer@chromium.org
      BUG=v8:4764
      
      Review-Url: https://codereview.chromium.org/2230783004
      Cr-Commit-Position: refs/heads/master@{#38548}
      685210ec
  3. 05 Aug, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Fix profiler when hitting OSR frame. · f00b42ae
      mstarzinger authored
      This fixes the runtime profiler to no longer assume that seeing an
      optimized frame on the stack implies the underlying function is not
      being interpreted when entered normally. This no longer holds with code
      generated for OSR directly from bytecode (not installed on function).
      
      R=rmcilroy@chromium.org
      TEST=mjsunit/regress/regress-crbug-632800
      BUG=chromium:632800
      
      Review-Url: https://codereview.chromium.org/2208603005
      Cr-Commit-Position: refs/heads/master@{#38360}
      f00b42ae
  4. 25 Jul, 2016 1 commit
  5. 21 Jul, 2016 2 commits
  6. 16 May, 2016 1 commit
  7. 25 Apr, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Add baseline tier to compilation pipeline. · 3fc0224c
      mstarzinger authored
      This adds a baseline tier to the compilation pipeline. Currently this
      tier is used to model a path from the interpreter to optimized code via
      full-codegen code (to ensure sufficient type feedback). Switching from
      the unoptimized tier to the baseline tier is limited to happen only when
      there are no activations of the given function on the stack.
      
      R=rmcilroy@chromium.org,bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1903273004
      
      Cr-Commit-Position: refs/heads/master@{#35757}
      3fc0224c
  8. 19 Feb, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Enable runtime profiler support for Ignition. · b62bf1e6
      rmcilroy authored
      Adds a profiling counter to each BytecodeArray object, and adds
      code to Jump and Return bytecode handlers to update this
      counter by the size of the jump or the distance from the return
      to the start of the function. This is more accurate than fullcodegen's
      approach since it takes forward jumps into account as well as back-edges.
      
      Modifies RuntimeProfiler to track ticks for interpreted frames.
      Currently we use the SharedFunctionInfo::profiler_ticks() instead
      of adding another to tick field to avoid adding another field to
      BytecodeArray since SharedFunctionInfo::profiler_ticks() is only
      used by Crankshaft otherwise so we shouldn't need both for
      
      BUG=v8:4689
      LOG=N
      
      Review URL: https://codereview.chromium.org/1707693003
      
      Cr-Commit-Position: refs/heads/master@{#34166}
      b62bf1e6
  9. 30 Sep, 2015 1 commit
  10. 30 Jun, 2014 1 commit
  11. 24 Jun, 2014 1 commit
  12. 05 Jun, 2014 1 commit
  13. 03 Jun, 2014 1 commit
  14. 29 Apr, 2014 1 commit
  15. 06 Dec, 2013 1 commit
  16. 29 Jul, 2013 1 commit
  17. 14 Jun, 2013 1 commit
  18. 10 Apr, 2013 1 commit
  19. 12 Dec, 2012 1 commit
  20. 07 Dec, 2012 1 commit
  21. 05 Apr, 2012 1 commit
  22. 27 Mar, 2012 1 commit
  23. 12 Mar, 2012 1 commit
  24. 22 Feb, 2012 1 commit
  25. 09 Feb, 2012 2 commits
  26. 13 Jan, 2012 1 commit
  27. 11 Aug, 2011 1 commit
  28. 05 Jul, 2011 1 commit
  29. 29 Jun, 2011 1 commit
    • vitalyr@chromium.org's avatar
      Suspend runtime profiler as soon as we exit JS. · 90c9f1b9
      vitalyr@chromium.org authored
      Lots of web pages have really frequently firing timers that keep the
      profiler thread spinning if we require a period of JS inactivity
      before suspending the profiler. While it's possible to throttle it by
      increasing the sleep delay and adjusting the duration of the required
      inactive period, it seemed much simpler to just stop it immediately on
      exiting JS.
      
      Stopping the profiler this way effectively turned off two optimization
      heuristics: 1) eager optimization (it's reset on waking up the
      profiler and now the profiler wakes up much more frequently) and 2)
      optimization throttling based on JS to non-JS state ratio (the ratio
      is now 100%). I removed these two heuristics and found no performance
      regressions so far.
      
      R=ager@chromium.org
      BUG=crbug.com/77625
      TEST=none
      
      Review URL: http://codereview.chromium.org/7274024
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8472 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      90c9f1b9
  30. 12 Apr, 2011 1 commit
  31. 10 Apr, 2011 1 commit
  32. 18 Mar, 2011 3 commits
  33. 02 Mar, 2011 1 commit
  34. 07 Dec, 2010 1 commit
  35. 17 Nov, 2010 1 commit
  36. 02 Jun, 2010 1 commit