1. 04 Apr, 2019 1 commit
  2. 27 Nov, 2018 1 commit
  3. 12 Oct, 2018 1 commit
  4. 20 Sep, 2018 1 commit
  5. 11 Sep, 2018 1 commit
  6. 10 Aug, 2018 1 commit
    • Bret Sepulveda's avatar
      Escape backslashes when logging. · f642de00
      Bret Sepulveda authored
      Log::MessageBuilder was already escaping most unsafe characters when
      they were being logged, but plain backslashes were not. Merely updating
      the existing escaping path was not sufficient, as recursion would cause
      escape codes to be doubly escaped. This patches refactors the API to
      ensure incoming text is escaped exactly once.
      
      Bug: v8:8039
      Change-Id: Id48aabf29fb6153189ae4a1ad7dfaaf4b41b62ad
      Reviewed-on: https://chromium-review.googlesource.com/1169049Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Bret Sepulveda <bsep@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55038}
      f642de00
  7. 03 May, 2018 2 commits
  8. 23 Mar, 2018 1 commit
  9. 21 Mar, 2018 1 commit
  10. 20 Dec, 2017 1 commit
  11. 14 Nov, 2017 1 commit
  12. 30 Oct, 2017 1 commit
  13. 24 Oct, 2017 1 commit
  14. 20 Oct, 2017 4 commits
  15. 13 Oct, 2017 1 commit
  16. 28 Jul, 2017 1 commit
  17. 20 Feb, 2017 1 commit
  18. 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
  19. 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
  20. 14 Oct, 2016 1 commit
  21. 12 Apr, 2016 1 commit
  22. 11 Apr, 2016 2 commits
  23. 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
  24. 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
  25. 30 Oct, 2015 1 commit
  26. 05 Oct, 2015 1 commit
  27. 30 Sep, 2015 1 commit
  28. 14 Aug, 2015 1 commit
  29. 29 May, 2015 1 commit
  30. 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
  31. 04 Aug, 2014 1 commit
  32. 30 Jun, 2014 1 commit
  33. 03 Jun, 2014 1 commit