- 01 Dec, 2016 1 commit
-
-
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}
-
- 24 Nov, 2016 2 commits
-
-
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}
-
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}
-
- 14 Oct, 2016 1 commit
-
-
yangguo authored
There is no user for this log entry, and a large part of regexp log output has long been removed already. R=jgruber@chromium.org Review-Url: https://codereview.chromium.org/2422593003 Cr-Commit-Position: refs/heads/master@{#40316}
-
- 12 Apr, 2016 1 commit
-
-
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. Original CL: https://codereview.chromium.org/1869433004 Reverted in: https://codereview.chromium.org/1867383002 Reverted again in: https://codereview.chromium.org/1877823003 Reverts due to non-CQ bots: - First: v8_win_dbg, v8_win64_dbg, v8_mac_dbg - Second: gc mole (added to v8_linux_rel_ng for this patch) R= jochen@chromium.org TBR= ahaas@chromium.org,bmeurer@chromium.org,yangguo@chromium.org Review URL: https://codereview.chromium.org/1872203005 Cr-Commit-Position: refs/heads/master@{#35423}
-
- 11 Apr, 2016 2 commits
-
-
https://codereview.chromium.org/1877453002/machenbach authored
Reason for revert: Breaks gc mole: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/9421 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. > > Original CL: https://codereview.chromium.org/1869433004 > Reverted in: https://codereview.chromium.org/1867383002 > > R= jochen@chromium.org > TBR= bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org > > Committed: https://crrev.com/bf505329288e1b75bab0e6800371a9aac40fa5cc > Cr-Commit-Position: refs/heads/master@{#35394} TBR=jochen@chromium.org,ahaas@chromium.org,bmeurer@chromium.org,yangguo@chromium.org,jfb@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/1877823003 Cr-Commit-Position: refs/heads/master@{#35396}
-
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. Original CL: https://codereview.chromium.org/1869433004 Reverted in: https://codereview.chromium.org/1867383002 R= jochen@chromium.org TBR= bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org Review URL: https://codereview.chromium.org/1877453002 Cr-Commit-Position: refs/heads/master@{#35394}
-
- 08 Apr, 2016 2 commits
-
-
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}
-
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}
-
- 29 Mar, 2016 1 commit
-
-
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}
-
- 30 Oct, 2015 1 commit
-
-
landell authored
BUG= Review URL: https://codereview.chromium.org/1418213007 Cr-Commit-Position: refs/heads/master@{#31669}
-
- 05 Oct, 2015 1 commit
-
-
dsinclair authored
The log-utils.h file uses va_list but doesn't require the header. This CL adds the needed header to remove a compiler error we've seen when doing some bisecting. Review URL: https://codereview.chromium.org/1383483004 Cr-Commit-Position: refs/heads/master@{#31110}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 14 Aug, 2015 1 commit
-
-
mstarzinger authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1297583002 Cr-Commit-Position: refs/heads/master@{#30172}
-
- 29 May, 2015 1 commit
-
-
jarin authored
BUG= Review URL: https://codereview.chromium.org/1148293009 Cr-Commit-Position: refs/heads/master@{#28697}
-
- 20 Jan, 2015 1 commit
-
-
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}
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
Also split v8-core independent methods from checks.h to base/logging.h and merge v8checks with the rest of checks. The CPU::FlushICache method is moved to CpuFeatures::FlushICache RoundUp and related methods are moved to base/macros.h Remove all layering violations from src/libplatform BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/358363002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 May, 2014 1 commit
-
-
mstarzinger@chromium.org authored
R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/265283007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21160 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Nov, 2013 1 commit
-
-
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
-
- 29 Aug, 2013 1 commit
-
-
bmeurer@chromium.org authored
Drop the previous Mutex and ScopedLock classes from platform files. Add new Mutex, RecursiveMutex and LockGuard classes, which are designed after their C++11 counterparts, so that at some point we can simply drop our custom code and switch to the C++11 classes. We distinguish regular and recursive mutexes, as the latter don't work well with condition variables, which will be introduced by a followup CL. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/23625003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16416 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Jul, 2013 1 commit
-
-
loislo@chromium.org authored
LogMessageBuilder is a helper class for Log. So I made it a nested class and removed the dependency from Logger. BUG=none TEST=no changes in the logic R=yangguo@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/19768003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15760 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 15 Jul, 2013 1 commit
-
-
loislo@chromium.org authored
four or even five different logging destinations. I think we can extract the code related to a destination into a separate class, do the same for the all destinations and have four classes with more or less simple common logging API BUG=none Meta-bug= https://code.google.com/p/chromium/issues/detail?id=260203 R=yangguo@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/18259024 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15664 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Jun, 2013 1 commit
-
-
loislo@chromium.org authored
We have 5 overloaded functions with name CreateCodeEvent. All these functions have many common parts. I'd like to eliminate the difference between them. TEST=existing tests R=yangguo@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/16901014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15287 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Apr, 2013 1 commit
-
-
yangguo@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/14139033 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14421 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Sep, 2011 1 commit
-
-
ricow@chromium.org authored
This is all blank line before/after linting errors. Review URL: http://codereview.chromium.org/7754022 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9204 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Aug, 2011 1 commit
-
-
vitalyr@chromium.org authored
R=vegorov@chromium.org Review URL: http://codereview.chromium.org/7491052 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8843 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Jul, 2011 2 commits
-
-
mikhail.naganov@gmail.com authored
The only usage of it was in logging tests, I've switched them for using a file. I've left out support for "--logfile=*" for now, as Chromium uses it. Will be removed after the next V8 roll. R=sgjesse@chromium.org BUG=859 TEST=mjsunit/log-* Review URL: http://codereview.chromium.org/7310025 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8629 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
The preprocessor defines ENABLE_LOGGING_AND_PROFILING and ENABLE_VMSTATE_TRACKING has been removed as these where required to be turned on for Crankshaft to work. To re-enable reducing the binary size by leaving out heap and CPU profiler a new set of defines needs to be created. R=ager@chromium.org BUG=v8:1271 TEST=all Review URL: http://codereview.chromium.org//7350014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 May, 2011 1 commit
-
-
svenpanne@chromium.org authored
header which uses BASE_EMBEDDED and/or AllStatic. Note that still only 45 out of 135 headers in src/ can be used stand-alone, but at least this is a little bit more than before... Review URL: http://codereview.chromium.org/6931031 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7798 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2011 1 commit
-
-
vitalyr@chromium.org authored
Switched to using binary low-level log instead of the textual log used by the ticks processor. The binary log contains code-related events, code object names, and their bodies. When writing to the log we ask glibc to use a larger buffer. To avoid complex processing of the snapshot log (which is still textual) the serializer emits final snapshot position to code name mappings that can be quickly be read without replaying the snapshot log. (This might be useful for the ticks processor.) Review URL: http://codereview.chromium.org/6904127 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7729 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Mar, 2011 3 commits
-
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7271 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
Review URL: http://codereview.chromium.org/6685088 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7268 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Dec, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
This is no longer used in Chromium, and only pollutes code. BUG=859 Review URL: http://codereview.chromium.org/5575006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5934 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Oct, 2010 1 commit
-
-
vitalyr@chromium.org authored
Since 2.6.31 perf_events interface has been available in the kernel. There's a nice tool called "perf" (linux-2.6/tools/perf) that uses this interface and provides capabilities similar to oprofile. The simplest form of its usage is just dumping the raw log (trace) of events generated by the kernel. In this patch I'm adding a script (tools/ll_prof.py) to build profiles based on perf trace and our code log. All the heavy-lifting is done by perf. Compared to oprofile agent this approach does not require recompilation and supports code moving garbage collections. Expected usage is documented in the ll_prof's help. Basically one should run V8 under perf passing --ll-prof flag and then the produced logs can be analyzed by tools/ll_prof.py. The new --ll-prof flag enables logging of generated code object locations and names (like --log-code), and also of their bodies, which can be later disassembled and annotated by the script. Review URL: http://codereview.chromium.org/3831002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Sep, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
BUG=868 Review URL: http://codereview.chromium.org/3605001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5565 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Mar, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
Review URL: http://codereview.chromium.org/799008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4097 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-