1. 20 Dec, 2017 1 commit
  2. 14 Nov, 2017 1 commit
  3. 30 Oct, 2017 1 commit
  4. 24 Oct, 2017 1 commit
  5. 20 Oct, 2017 4 commits
  6. 13 Oct, 2017 1 commit
  7. 28 Jul, 2017 1 commit
  8. 20 Feb, 2017 1 commit
  9. 01 Dec, 2016 1 commit
    • clemensh's avatar
      [base] Define CHECK comparison for signed vs. unsigned · db0c86fa
      clemensh authored
      The current CHECK/DCHECK implementation fails statically if a signed
      value is compared against an unsigned value. The common solution is to
      cast on each caller, which is tedious and error-prone (might hide bugs).
      This CL implements signed vs. unsigned comparisons by executing up to
      two comparisons. For example, if i is int32_t and u is uint_32_t, a
      DCHECK_LE(i, u) would create the check
      i <= 0 || static_cast<uint32_t>(i) <= u.
      For checks against constants, at least one of the checks can be removed
      by compiler optimizations.
      
      The tradeoff we have to make is to sometimes silently execute an
      additional comparison. And we increase code complexity of course, even
      though the usage is just as easy (or even easier) as before.
      
      The compile time impact seems to be minimal:
      I ran 3 full compilations for Optdebug on my local machine, one time on
      the current ToT, one time with this CL plus http://crrev.com/2524093002.
      Before: 143.72 +- 1.21 seconds
      Now: 144.18 +- 0.67 seconds
      
      In order to check that the new comparisons are working, I refactored
      some DCHECKs in wasm to use the new magic, and added unit test cases.
      
      R=ishell@chromium.org, titzer@chromium.org
      CC=ahaas@chromium.org, bmeurer@chromium.org
      
      Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
      Review-Url: https://codereview.chromium.org/2526783002
      Cr-Original-Commit-Position: refs/heads/master@{#41275}
      Cr-Commit-Position: refs/heads/master@{#41411}
      db0c86fa
  10. 24 Nov, 2016 2 commits
    • clemensh's avatar
      Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5... · 0406620c
      clemensh authored
      Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5 id:80001 of https://codereview.chromium.org/2526783002/ )
      
      Reason for revert:
      Need to revert previous CL because of Android compile error, and this one depends in it.
      
      Original issue's description:
      > [base] Define CHECK comparison for signed vs. unsigned
      >
      > The current CHECK/DCHECK implementation fails statically if a signed
      > value is compared against an unsigned value. The common solution is to
      > cast on each caller, which is tedious and error-prone (might hide bugs).
      > This CL implements signed vs. unsigned comparisons by executing up to
      > two comparisons. For example, if i is int32_t and u is uint_32_t, a
      > DCHECK_LE(i, u) would create the check
      > i <= 0 || static_cast<uint32_t>(i) <= u.
      > For checks against constants, at least one of the checks can be removed
      > by compiler optimizations.
      >
      > The tradeoff we have to make is to sometimes silently execute an
      > additional comparison. And we increase code complexity of course, even
      > though the usage is just as easy (or even easier) as before.
      >
      > The compile time impact seems to be minimal:
      > I ran 3 full compilations for Optdebug on my local machine, one time on
      > the current ToT, one time with this CL plus http://crrev.com/2524093002.
      > Before: 143.72 +- 1.21 seconds
      > Now: 144.18 +- 0.67 seconds
      >
      > In order to check that the new comparisons are working, I refactored
      > some DCHECKs in wasm to use the new magic.
      >
      > R=bmeurer@chromium.org, titzer@chromium.org
      >
      > Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
      > Cr-Commit-Position: refs/heads/master@{#41275}
      
      TBR=ishell@chromium.org,titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review-Url: https://codereview.chromium.org/2531533003
      Cr-Commit-Position: refs/heads/master@{#41277}
      0406620c
    • clemensh's avatar
      [base] Define CHECK comparison for signed vs. unsigned · 5925074a
      clemensh authored
      The current CHECK/DCHECK implementation fails statically if a signed
      value is compared against an unsigned value. The common solution is to
      cast on each caller, which is tedious and error-prone (might hide bugs).
      This CL implements signed vs. unsigned comparisons by executing up to
      two comparisons. For example, if i is int32_t and u is uint_32_t, a
      DCHECK_LE(i, u) would create the check
      i <= 0 || static_cast<uint32_t>(i) <= u.
      For checks against constants, at least one of the checks can be removed
      by compiler optimizations.
      
      The tradeoff we have to make is to sometimes silently execute an
      additional comparison. And we increase code complexity of course, even
      though the usage is just as easy (or even easier) as before.
      
      The compile time impact seems to be minimal:
      I ran 3 full compilations for Optdebug on my local machine, one time on
      the current ToT, one time with this CL plus http://crrev.com/2524093002.
      Before: 143.72 +- 1.21 seconds
      Now: 144.18 +- 0.67 seconds
      
      In order to check that the new comparisons are working, I refactored
      some DCHECKs in wasm to use the new magic.
      
      R=bmeurer@chromium.org, titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2526783002
      Cr-Commit-Position: refs/heads/master@{#41275}
      5925074a
  11. 14 Oct, 2016 1 commit
  12. 12 Apr, 2016 1 commit
  13. 11 Apr, 2016 2 commits
  14. 08 Apr, 2016 2 commits
    • jfb's avatar
      Revert of Fix printf formats (patchset #8 id:140001 of... · 4c4fdc2d
      jfb authored
      Revert of Fix printf formats (patchset #8 id:140001 of https://codereview.chromium.org/1869433004/ )
      
      Reason for revert:
      One small issue easily fixed here: https://codereview.chromium.org/1867333003/
      
      But it looks like MSVS 2013 doesn't like some of the formats and exists with the unhelpful:
      Stderr:
      f:\dd\vctools\crt\crtw32\stdio\output.c(1125) : Assertion failed: ("Incorrect
      format specifier", 0)
      
      It's easier to revert for now, I'll dig more into the docs:
      https://msdn.microsoft.com/en-us/library/56e442dc(v=vs.120).aspx
      https://msdn.microsoft.com/en-us/library/tcxf1dw6(v=vs.120).aspx
      
      And then resubmit, making sure I run these bots.
      
      Original issue's description:
      > Fix printf formats
      >
      > The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:
      >
      >  - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
      >  - Uses it appropriately.
      >  - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
      >  - Fixes a bunch of incorrect formats.
      >
      > R= jochen@chromium.org, bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org
      >
      > Committed: https://crrev.com/6ebf9fbb93d31f9be41156a3325d58704ed4933d
      > Cr-Commit-Position: refs/heads/master@{#35365}
      
      TBR=jochen@chromium.org,bmeurer@chromium.org,yangguo@chromium.org,ahaas@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1867383002
      
      Cr-Commit-Position: refs/heads/master@{#35366}
      4c4fdc2d
    • jfb's avatar
      Fix printf formats · 6ebf9fbb
      jfb authored
      The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:
      
       - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
       - Uses it appropriately.
       - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
       - Fixes a bunch of incorrect formats.
      
      R= jochen@chromium.org, bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org
      
      Review URL: https://codereview.chromium.org/1869433004
      
      Cr-Commit-Position: refs/heads/master@{#35365}
      6ebf9fbb
  15. 29 Mar, 2016 1 commit
    • jarin's avatar
      Linux perf integration with the new support for JIT. · 82e95f59
      jarin authored
      Difference from --perf-basic-prof:
      - correctly attributes samples when code space gets reused (when unused code object dies and a new code objects is allocated at the same place).
      - outputs compiled machine code for instruction-level profile.
      
      Just like --perf-basic-prof, the file writer is not synchronized (even worse, there is a per-isolate file handle), so we will run into trouble with multiple isolates. However, this patch is still an improvement on --perf-basic-prof, and it should be fine to replace ll-prof.
      
      The patch also introduces experimental support for debug info, but it does not seem to be picked by the perf tool.
      
      Usage:
      
      You need the perf tool from Linux kernel >4.5. Then run:
      
      $ perf record -k mono d8 --perf-prof <your JS file>
      $ perf inject -j -i perf.data -o perf.data.jitted
      $ perf report -i perf.data.jitted
      
      Some explanations:
      The "-k mono" switch from "perf record" tells the perf tool to use the monotonic clock for perf sample timestamping. The "perf inject -j" command injects the collected code events into the perf data file, writing the output into perf.data.jitted. The perf report command then creates the report.
      
      Review URL: https://codereview.chromium.org/1809203007
      
      Cr-Commit-Position: refs/heads/master@{#35091}
      82e95f59
  16. 30 Oct, 2015 1 commit
  17. 05 Oct, 2015 1 commit
  18. 30 Sep, 2015 1 commit
  19. 14 Aug, 2015 1 commit
  20. 29 May, 2015 1 commit
  21. 20 Jan, 2015 1 commit
    • jkummerow's avatar
      Profiler improvements · feffccca
      jkummerow authored
      (1) --prof-cpp: Collects ticks like --prof, but ignores code creation events to reduce distortion (so all JS ticks will be "unaccounted"). Useful for profiling C++ code.
      (2) --timed-range flag for tick processor: Ignores ticks before the first and after the last call to Date.now(). Useful for focusing on the timed section of a test.
      
      Review URL: https://codereview.chromium.org/802333002
      
      Cr-Commit-Position: refs/heads/master@{#26168}
      feffccca
  22. 04 Aug, 2014 1 commit
  23. 30 Jun, 2014 1 commit
  24. 03 Jun, 2014 1 commit
  25. 06 May, 2014 1 commit
  26. 29 Apr, 2014 1 commit
  27. 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
  28. 29 Aug, 2013 1 commit
  29. 18 Jul, 2013 1 commit
  30. 15 Jul, 2013 1 commit
  31. 24 Jun, 2013 1 commit
  32. 24 Apr, 2013 1 commit
  33. 08 Sep, 2011 1 commit
  34. 05 Aug, 2011 1 commit