1. 15 Feb, 2016 1 commit
  2. 05 Feb, 2016 1 commit
  3. 04 Dec, 2015 1 commit
  4. 01 Dec, 2015 1 commit
  5. 30 Sep, 2015 1 commit
  6. 29 Jun, 2015 1 commit
    • Djordje.Pesic's avatar
      Assertion failure when using --log-regexp · 7be96aa2
      Djordje.Pesic authored
      RegExpCompileEvent acquieres mutex from Log class during MessageBuilder creation. LogRegExpSource, called from RegExpCompileEvent creates another MessageBuilder object which also acquires the same mutex. This mutex is not recursive, so during second acquirement, assertion fail is happening. Solution: LogRegExpSource should use the same MessageBuilder object as RegExpCompileEvent.
      
      Review URL: https://codereview.chromium.org/1207433002
      
      Cr-Commit-Position: refs/heads/master@{#29347}
      7be96aa2
  7. 29 May, 2015 1 commit
  8. 15 May, 2015 1 commit
  9. 09 Mar, 2015 1 commit
    • loislo's avatar
      CpuProfiler: fix for GetDeoptReason code. · 66ab309e
      loislo authored
      The original code always returned the first entry from RelocInfo that matched with
      bailout_id. But we may have a few different deopt reasons for one bailout_id.
      So we need to get the one which matches with a particular call from JumpTable.
      
      We can do this by checking not 'target_address' (it maps to bailout_id)
      but 'from' address which maps to a particular JumpTable entry.
      
      The test was reworked so it tests identical functions against different reasons.
      
      BUG=chromium:452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/984773003
      
      Cr-Commit-Position: refs/heads/master@{#27076}
      66ab309e
  10. 26 Feb, 2015 1 commit
  11. 10 Feb, 2015 1 commit
    • loislo's avatar
      Propagate DeoptInfo to cpu-profiler · 86cae163
      loislo authored
      1) Deoptimizer::Reason was replaced with Deoptimizer::DeoptInfo
      because it also has raw position. Also the old name clashes with DeoptReason enum.
      
      2) c_entry_fp assignment call was added to EntryGenerator::Generate
      So we can calculate sp and have a chance to record the stack for the deopting function.
      btw it makes the test stable.
      
      3) new kind of CodeEvents was added to cpu-profiler
      
      4) GetDeoptInfo method was extracted from PrintDeoptLocation.
      So it could be reused in cpu profiler.
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/910773002
      
      Cr-Commit-Position: refs/heads/master@{#26545}
      86cae163
  12. 15 Oct, 2014 1 commit
  13. 14 Oct, 2014 1 commit
  14. 16 Jul, 2014 1 commit
  15. 30 Jun, 2014 1 commit
  16. 13 Jun, 2014 1 commit
  17. 12 Jun, 2014 1 commit
  18. 10 Jun, 2014 1 commit
  19. 03 Jun, 2014 1 commit
  20. 22 May, 2014 1 commit
  21. 06 May, 2014 1 commit
  22. 30 Apr, 2014 1 commit
  23. 29 Apr, 2014 1 commit
  24. 04 Apr, 2014 2 commits
  25. 03 Apr, 2014 2 commits
  26. 18 Mar, 2014 1 commit
  27. 10 Mar, 2014 1 commit
  28. 31 Jan, 2014 1 commit
  29. 07 Jan, 2014 1 commit
  30. 25 Nov, 2013 1 commit
    • jarin@chromium.org's avatar
      Support for the Linux 'perf report' and 'perf annotate' tools. · 4e439deb
      jarin@chromium.org authored
      In this change, the support comes in two flavours:
      
      --perf_jit_prof - outputs the files in a new perf format that only works with a
      patched perf tool (patch obtained from Stephane Eranian). Both 'perf report' and
      'perf annotate' are supported (the file format also contains the machine code).
      
      --perf_basic_prof - outputs the files in a format that the existing perf tool
      can consume. Only 'perf report' is supported.
      
      In both cases, we have to disable code compaction because the perf tool does not
      understand code relocation. (We are told that code relocation should be
      supported soon.)
      
      Usage:
      
      perf record -g d8 --perf_jit_prof --no_compact_code_space my.js
      perf report
      
      The change itself is straightforward - we simply listen to code events and
      write an entry to a log file for every new piece of code.
      
      I am not yet sure whether we should keep both versions or just one (and which
      one). My hope is the reviewers can help here.
      
      R=danno@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/70013002
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18034 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      4e439deb
  31. 10 Oct, 2013 1 commit
  32. 30 Sep, 2013 1 commit
  33. 29 Aug, 2013 2 commits
  34. 28 Aug, 2013 4 commits