Re: [chromium-dev] Symbolized backtrace on Linux chromium?
On Mon, Nov 30, 2009 at 9:37 AM, Chris Bentzel wrote: > When DCHECK's trigger on my debug chromium build, I get an unsymbolized > stacktrace like > [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: > !request_. > [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: > !request_. > Backtrace: > out/Debug/chrome [0x8d7d9bc] > out/Debug/chrome [0x8d99838] > out/Debug/chrome [0x8fba726] > out/Debug/chrome [0x8fb7f7b] > out/Debug/chrome [0x8fb7f8f] > out/Debug/chrome [0x8fb90e1] > out/Debug/chrome [0x8fb9444] > /usr/lib/libnss3.so.1d [0xb7884ed4] > /usr/lib/libnss3.so.1d [0xb788ed68] > /usr/lib/libnss3.so.1d [0xb783533a] > /usr/lib/libnss3.so.1d [0xb7836020] > /usr/lib/libnss3.so.1d [0xb784e8dd] > /usr/lib/libnss3.so.1d [0xb7852527] > /usr/lib/libnss3.so.1d [0xb78535a7] > /usr/lib/libnss3.so.1d [0xb7858548] > /usr/lib/libnss3.so.1d [0xb785a5b6] > /usr/lib/libnss3.so.1d(CERT_PKIXVerifyCert+0x464) [0xb77d7ce4] > out/Debug/chrome [0x90ee205] > out/Debug/chrome [0x90eeed7] > out/Debug/chrome [0x90b3ed5] > out/Debug/chrome [0x90b399e] > out/Debug/chrome [0x90b39d9] > out/Debug/chrome [0xa00ec3c] > out/Debug/chrome [0x8dafe2e] > /lib/tls/i686/cmov/libpthread.so.0 [0xb77044fb] > /lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb73a2e5e] > It looks like this was built with the -g option, and file out/Debug/chrome > shows that it's not stripped. This was built from head this morning. > Is there a reason I'm not getting symbols to display here? I'm not really sure, but it's sort of interesting that you do seem to get it for certain functions in the system libs. I noticed this issue too recently. I think it's been the case for perhaps the past few weeks or so. My almost completely ungrounded suspicion is it has to do with some of the changes Evan made to shrink the chrome binary size, but I haven't investigated. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Are we going to use tcmalloc on Mac?
On Tue, Oct 27, 2009 at 9:10 PM, Mike Belshe wrote: > On Tue, Oct 27, 2009 at 3:24 PM, Jens Alfke wrote: >> >> Do we plan to switch the Mac build of Chromium to use tcmalloc instead of >> the system malloc? I thought this was the case, but I can't find any bug >> covering the task to do that. I'm on the memory task force, and this >> decision could definitely have an impact (one direction or the other) on >> footprint on Mac. > > From a performance perspective, it may be critical to use tcmalloc to match > safari performance. It was literally a 50% speedup on most of the DOM perf > when running on WinXP. Just thought I'd throw in the data point that I've experimented with enabling tcmalloc for Linux builds of Chromium and the perfbots had negligible changes. I haven't had time to investigate why. I'd recommend you enable it for a run on the perfbots before you spend much time tweaking the mac port of tcmalloc. > >> >> I just tried enabling tcmalloc (by changing USE_SYSTEM_MALLOC to 0 in >> JavaScriptCore.gyp), and Chromium launches but logs a ton of warnings about >> unknown pointers being freed. > > I suspect this will use the version of TCMalloc which is embedded in WTF. > I'd recommend against this approach. We should try to use a single > allocator for the entire app, and specialize when necessary. Having the > rendering engine drive the allocator is a bit backwards; it seems better for > chrome itself to choose the allocator and then the rendering engine should > use that. > To make this work, you'll need to figure out whatever build magic is > necessary on the Mac; I'm kinda clueless in that regard, but if you want to > know what we did on Windows, I'm happy to share. > You'll find the tcmalloc version that we use on windows available in > third_party/tcmalloc. > Keep in mind also that the version of tcmalloc in webcore is heavily > modified by apple. Some of those changes have been similarly made in > tcmalloc's open source project, but others have not. Apple has not seemed > interested in syncing back and appears to be on the "fork it" route. > Using third_party/tcmalloc will offer a couple of advantages: > - we are continuing to improve it all the way from google3 to the > google-perftools to chrome. > - it will provide the same allocator on windows and mac (easier > debugging) > - the chromium implementation allows for selection of multiple allocators > fairly easily. Using the allocator_shim.cc, you can plug in your own > allocators pretty quickly. > There is a disadvantage. I suspect Apple is farther along in optimizing the > mac-specific optimizations of tcmalloc than the google3 guys are. You may > have to stumble into these. Either Jim or I could probably give you some > pointers for what to look at. tcmalloc is solid, but the ports other than > linux have had some very serious port related bugs. > Mike > >> >> I think this happens because tcmalloc is built by the 'wtf' target of >> JavaScriptCore.xcodeproj, which is a static library, so we may be ending up >> with multiple instances of the library with their own copies of its globals, >> leading to this problem if one instance allocates a block and another one >> tries to free it. But this usually happens only if there are multiple >> dynamic libraries using the same static library — do we have more than just >> Chromium.framework? >> —Jens >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Linux] tcmalloc && google-perftools profiling
I've checked in a change to enable tcmalloc on Linux via a gyp flag (r24538). If you set the gyp variable linux_use_tcmalloc to 1, it will build the tcmalloc library (which includes the cpu profiler and the heap profiler). You can then generate cpu profiles and heap profiles for Chromium on Linux and analyze them with the google-perftools pprof script. I've written up the basics of this at http://code.google.com/p/chromium/wiki/LinuxProfiling. For an example of what a Chromium cpu profile looks like, take a look at http://chromium.googlecode.com/issues/attachment?aid=8129389678904867605&name=cpuprofile.pdf which shows the heavy cpu usage of our tabstrip code. -Will PS: I haven't enabled tcmalloc by default because the perf cycler results didn't change substantially in the experiments I ran on the buildbots. The memory bot isn't working yet for Linux, so I'm also concerned about an increase in memory usage, so I'm waiting for that to be enabled before experimenting with this again. PPS: google-perftools profiling only works on the browser process for now, due to various issues that can be addressed (needing filesystem access to write out the profiles [doesn't work with sandbox], profile filename is specified in an environment variable, which is the same value across browser/renderer processes, etc.). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
Doubtful. It's designed for ELF binaries. On Tue, Aug 25, 2009 at 2:39 PM, Linus Upson wrote: > Any chance gold will support linking Windows binaries? > Linus > > On Tue, Aug 25, 2009 at 7:23 AM, Joel Stanley wrote: >> >> On Tue, Aug 25, 2009 at 17:06, Lei Zhang wrote: >> >> > Only x86 and x86_64 were supported at the time gold was originally >> > released. Does it support ARM yet? >> >> Yes, gold can link ARM binaries as of a few months ago. I have used >> it in my cross compiling. >> >> Ubuntu is shipping it it in Karmic (for ARM, as well as the x86 >> architectures) in the binutils-gold package. >> >> Joel >> >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
On Thu, Aug 20, 2009 at 10:26 AM, Evan Martin wrote: > > How does the v8 perf look like relative to 32-bit? > > I guess we ought to set up perf bots for startup/memory/etc. as well; > I'd expect we improve on those metrics on our 64-bit buildbots due to > more sharing with other apps on the system. I don't think we have the memory perfbot working yet, since it's blocked on http://code.google.com/p/chromium/issues/detail?id=9653. I agree it'd be nice to see how the perf dashboard compares between 32/64bit. > > On Thu, Aug 20, 2009 at 8:44 AM, Dean McNamee wrote: >> >> The v8 team did some amazing work this quarter building a working >> 64-bit port. After a handful of changes on the Chromium side, I've >> had Chromium Linux building on 64-bit for the last few weeks. I >> believe mmoss or tony is going to get a buildbot running, and working >> on packaging. >> >> You can follow the build instructions at: >> >> http://code.google.com/p/chromium/wiki/LinuxChromium64 >> >> It also looks like FTA has updated his daily builds so that the 64-bit >> packages are true 64-bit: >> >> https://launchpad.net/~chromium-daily/+archive/ppa >> >> Enjoy them big pointers, >> -- dean >> >> > >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
w00t, nice job. On Thu, Aug 20, 2009 at 8:44 AM, Dean McNamee wrote: > > The v8 team did some amazing work this quarter building a working > 64-bit port. After a handful of changes on the Chromium side, I've > had Chromium Linux building on 64-bit for the last few weeks. I > believe mmoss or tony is going to get a buildbot running, and working > on packaging. > > You can follow the build instructions at: > > http://code.google.com/p/chromium/wiki/LinuxChromium64 > > It also looks like FTA has updated his daily builds so that the 64-bit > packages are true 64-bit: > > https://launchpad.net/~chromium-daily/+archive/ppa > > Enjoy them big pointers, > -- dean > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Help with logging in Linux.
Try --user-data-dir. On Mon, Jul 6, 2009 at 7:49 PM, Anand Mistry wrote: > Thanks. That explains a lot. Is there any way to have chromium use a > different profile? I use chromium as my day-to-day browser and I'd rather > not have to exit whenever I need to run my own build. > > On Tue, Jul 7, 2009 at 1:53 AM, Dean McNamee wrote: >> >> If it "detaches from the terminal" this probably means you have >> another instance of Chromium already running. We check the profile >> lock on startup, and if there is already a running process holding >> that lock, we message it to create a new window. >> >> This might not be it, but it kinda sounds like it. Otherwise I would >> debug / strace / etc to figure out what's going on. >> >> On Mon, Jul 6, 2009 at 6:43 AM, Anand wrote: >> > >> > Hi all, >> > >> > I'm working on one of the bugs in chrome and the thing that's halted >> > my progress is that I can't get logging to work on Linux. I build >> > chrome in Debug mode, but when I launch it (with --log-level=0), it >> > spits out a few log message and then detaches from the terminal. I get >> > no further logging despite littering my code with LOG(INFO) messages. >> > I'm not building with any special flags, just 'hammer chrome' and I'm >> > just running with ' --log-level=0' and nothing else. Help! >> > >> > > >> > > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: about gtest's main in chromium
printing_unittests depends on gtestmain.lib. See src/printing/printing.gyp. On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davis wrote: > yep, for base_unittests, that's true. > But what I want to know is how chromium uses GTest. An important problem is > how it runs all the GTest projects. > Take the simplest GTest project printing_unittests as an example, I know > it's run via GTest's main in run_all_unittests.cc. But I don't know how it > invokes the main. I checked the project properties of printing_unittests, > and didn't find a link to gtestmain.lib as I always do while writing GTest > tests. > > > 2009/6/23 Adam Langley >> >> On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davis wrote: >> > But I find something weird in the chromiun's GTest projects, they >> > neither >> > write a main nor link a gtest_main.lib. >> > >> > How do they start GTest? >> >> Well, you can always set a breakpoint at main and see where you end >> up. For base_unittests, it's base/run_all_unittests.cc for example. >> >> >> AGL > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] git isn't sync'ing latest svn revisions for me
Hi, I dunno what's up, but git isn't sync'ing to the latest svn revisions for me: (21:37:35) willchan: any git experts around? (21:37:35) mdengfeng left the room (quit: Read error: 104 (Connection reset by peer)). (21:38:21) willchan: my git repo isn't syncing the latest svn revisions, gives me an error like (21:38:32) willchan: Index mismatch: ab650084ec5d9d308af33d7417442925d645a149 != 9951dd9bfdc1b0cecbad98604aaf9f3f28de27cc (21:38:59) markybob: heh, true, those are != :P (21:39:12) willchan: :) (21:39:24) dave_levin: willchan: I would delete that branch. (21:39:40) willchan: dave_levin: i created a new branch that had the same prob :( (21:39:42) dave_levin: then recreated it (21:39:45) dave_levin: oh (21:39:47) dave_levin: bummer (21:42:26) shenki: pulling the latest changes wfm (21:45:52) willchan: for some reason it seems i can only sync up to r18549 (21:46:48) shenki: that's not the latest commit? (21:46:54) willchan: no (21:46:57) shenki: oh (21:47:01) willchan: it's 6 hours ago (21:47:08) shenki: i assumed it was, as that's the latest im getting = willc...@panda:/usr/local/google/chromium4/src$ git checkout -b new_test origin Branch new_test set up to track remote branch refs/remotes/origin/trunk. Switched to a new branch "new_test" willc...@panda:/usr/local/google/chromium4/src$ git pull Already up-to-date. willc...@panda:/usr/local/google/chromium4/src$ git log -n5 commit 5aa424b09d8ee966947e69e82244550e40e4c787 Author: t...@chromium.org Date: Tue Jun 16 22:44:58 2009 + Add a small untility for checking to see if the X server is alive. This will be used by the buildbots after Xvfb is executated to make sure that Xvfb is alive. Review URL: http://codereview.chromium.org/126165 git-svn-id: svn://svn.chromium.org/chrome/trunk/s...@18549 0039d316-1c4b-4281-b951-d872f2087c98 ... willc...@panda:/usr/local/google/chromium4/src$ git svn fetch Index mismatch: ab650084ec5d9d308af33d7417442925d645a149 != 9951dd9bfdc1b0cecbad98604aaf9f3f28de27cc rereading 5aa424b09d8ee966947e69e82244550e40e4c787 A chrome/test/data/media/player.html A chrome/test/data/media/bear.mp4 A chrome/browser/media_uitest.cc Checksum mismatch: trunk/src/chrome/chrome.gyp c5184bb887fa26a89e4cd1894e6a9c96a866c020 expected: 0e4f507ffaca2f5c5070acfbc5cf2495 got: ad54c53174d56906eb5391091924f3dc === Can some git ninja help me out? Thanks :) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about chromium architecture
On Thu, Jun 4, 2009 at 12:35 AM, Mike Belshe wrote: > > > On Thu, Jun 4, 2009 at 12:30 AM, Meryl Silverburgh > wrote: >> >> On Wed, Jun 3, 2009 at 11:09 PM, Mike Belshe wrote: >> > >> > >> > On Wed, Jun 3, 2009 at 10:40 PM, Meryl Silverburgh >> > wrote: >> >> >> >> On Tue, Jun 2, 2009 at 5:00 PM, Brett Wilson >> >> wrote: >> >> > On Tue, Jun 2, 2009 at 4:57 PM, Meryl Silverburgh >> >> > wrote: >> >> >> >> >> >> I am reading this document >> >> >> >> >> >> >> >> >> "http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code"; >> >> >> about chromium source code: >> >> >> It said: >> >> >> >> >> >> renderer: Code for the subprocess in each tab. This embeds WebKit >> >> >> and >> >> >> talks to browser for I/O. >> >> >> >> >> >> Does that mean chromium do not use the HTTP stack/library that >> >> >> Webkit >> >> >> is using? >> >> > >> >> > WebKit uses different HTTP stacks depending on the port. We use a >> >> > different one than any other ports. >> >> > >> >> >> And does that mean all the I/O of each tab (webkit renderer) will be >> >> >> sent to 'browser' for I/O, and there is 1 I/O thread in the browser >> >> >> to >> >> >> handle the I/O requests from ALL tab? >> >> > >> >> > Correct. >> >> > >> >> >> >> That you. But if all I/O of the tab will be sent to and queued up in 1 >> >> I/O thread in 'browser', >> >> will that become the bottleneck (as supposed to each tab has its own >> >> i/o thread and each can load thing independently)? >> > >> > The rule is that the work done on the io thread needs to be very very >> > quick. >> > So far, we've been reasonably successful at that. We use automated >> > tests >> > to search for regressions. >> > But these are just theories. Run it in the profiler, and see for >> > yourself >> > if it works well :-) >> > >> >> Thank you for your clarification. >> If i understanding correctly, I/O thread needs to http request network >> resources (e.g. image files, js files, css files). And how fast that >> http request is done is dependent on how far the other end sending the >> file back, right? So it is not up to chromium find each i/o request >> very very quick. Am i right? I think the confusion here is you might be assuming that Chromium handles the I/O synchronously. Chromium handles it asynchronously, in chunks if necessary. Therefore, if the other end is not sending the data slowly, the Chromium I/O thread only reads as much as is available. Then it handles other I/O tasks or goes idle until more data becomes available. It does not block the I/O thread while waiting for servers to send data. > > Sure, but the thread is completely idle while we wait for the network and > can therefore do other things. The amount of CPU to fetch network resources > is tiny compared to the time to render them. The IO thread is effectively a > dispatcher here; he gets the network requests started, and does mild > processing of data when it arrives. But he hands the real work to the > renderer and the webkit thread. > Again, if you think there is a problem, open it up in a profiler. I've run > the profiler many times, and I don't think this is a bottleneck. > Mike > >> >> >> >> >> >> >> >> And does browser I/O thread gives priority to I/O from the current >> >> active tab (the only tab which is in the foreground)? >> > >> > If it ever profiles as a bottleneck, then we should definitely add >> > priorities. Right now, we don't do much. >> > Background tabs do take background priorities, which indirectly helps. >> > Mike >> > >> >> >> >> >> >> >> >> > Brett >> >> > >> >> >> >> >> >> > >> > > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] green flashes in page content
On Tue, May 19, 2009 at 5:12 PM, James Hawkins wrote: > > On Tue, May 19, 2009 at 5:07 PM, Evan Stade wrote: >>> Are we sure we need this functionality? I understand the intention of >>> seeing when we're not drawing fast enough, but I'm seeing the green >>> background all the time (on a fast machine), which leads me to believe >>> that the debugging aid is a red herring. >> >> Yea, you should see it all the time. We'll never be able to fix that. >> But how much of it you see is a good measure of jank. >> >> If enough people hate it, we can remove it (and only enable when we >> care to look at jank). >> > > We should leave page load/rendering time to measurements from the > tests. This should be something that a developer working on jankiness > could enable himself. It's rather distracting to the developers who > don't need to look into jankiness, but do need to run debug builds > regularly. I personally like seeing the green background, since I do like seeing how much jank there is. It doesn't bother me at all. That said, I can see how it'd annoy some people. If most people dislike it, then I think we should just make it the same as the release behavior (use a white background), but I think it'd be nice to have a command line flag or a preference or something so I can run with a green or whatever background to aid in debugging jankiness. > > -- > James Hawkins > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] chrome code size source lines
I don't know if anyone's already done this, but I figured I'd share the results in case anyone was curious. I'm using j...@google.com's script for parsing objdump output and sorting it. These results are generated by building a Release mode chrome with "-g2" added to get the line numbers. This is built with gcc on linux with a tree checked out two days ago or so. No surprise, but stl code figures prominently here. Looks like the webkit ref counting and containers also show up. [Column 1: Bytes per occurrence] [Column 2: Total bytes of generated code] [Column 3: Number of occurrences] [Column 4: Actual source file & line number] 30.5 34280211223 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/RefCounted.h:94 18.0 22174612310 /usr/include/c++/4.2/bits/basic_string.h:238 8.3 16937120511 /usr/include/c++/4.2/bits/basic_string.h:234 9.7 16848817451 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/RefCounted.h:67 29.7 155668 5236 /usr/include/c++/4.2/ostream:517 15.5 143931 9289 /usr/local/google/chromium4/src/third_party/WebKit/WebCore/platform/TreeShared.h:65 30.0 142957 4771 /usr/include/c++/4.2/ext/atomicity.h:51 8.1 12486915454 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/RefPtr.h:50 11.0 12029010931 /usr/include/c++/4.2/ext/atomicity.h:83 5.79852917262 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/RefCounted.h:74 7.27898710931 /usr/include/c++/4.2/bits/basic_string.h:236 6.57462211474 /usr/include/c++/4.2/bits/basic_string.h:288 20.872263 3481 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/Vector.h:462 13.671845 5284 /usr/local/google/chromium4/src/third_party/WebKit/WebCore/platform/TreeShared.h:69 13.068506 5283 /usr/local/google/chromium4/src/v8/include/v8.h:191 6.06587710931 /usr/include/c++/4.2/ext/atomicity.h:70 40.463852 1581 /usr/local/google/chromium4/src/webkit/port/bindings/v8/v8_proxy.h:366 36.450688 1392 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/HashTable.h:422 10.546967 4470 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/RefPtr.h:39 17.542025 2401 /usr/local/google/chromium4/src/third_party/icu38/public/common/unicode/unistr.h:3311 20.540907 2000 /usr/local/google/chromium4/src/v8/include/v8.h:2437 3.13407610910 /usr/include/c++/4.2/ext/atomicity.h:69 25.633080 1291 /usr/include/c++/4.2/bits/stl_vector.h:88 19.031160 1640 /usr/local/google/chromium4/src/v8/include/v8.h:240 18.130243 1674 /usr/local/google/chromium4/src/v8/include/v8.h:239 24.629691 1208 /usr/local/google/chromium4/src/third_party/WebKit/WebCore/svg/SVGDocumentExtensions.h:72 31.729620 933 /usr/local/google/chromium4/src/third_party/WebKit/WebCore/platform/KURLGooglePrivate.h:47 17.828586 1603 /usr/local/google/chromium4/src/webkit/port/bindings/v8/v8_proxy.h:494 16.025090 1566 /usr/include/c++/4.2/bits/basic_string.h:491 4.124803 6057 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/RefCounted.h:37 20.824332 1170 /usr/local/google/chromium4/src/third_party/WebKit/WebCore/svg/SVGAnimatedTemplate.h:120 16.723587 1414 /usr/local/google/chromium4/src/base/ref_counted.h:107 12.823532 1840 /usr/include/c++/4.2/bits/stl_algobase.h:187 28.823288 810 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/HashTable.h:323 33.222721 685 /usr/local/google/chromium4/src/v8/src/zone-inl.h:45 4.922286 4594 /usr/local/google/chromium4/src/third_party/WebKit/JavaScriptCore/wtf/RefPtr.h:54 28.122084 785 /usr/include/c++/4.2/iostream:77 For perspective: willc...@panda:/usr/local/google/chromium4/src$ size sconsbuild/Release/chrome textdata bss dec hex filename 175305398458168 122180 2611088718e6ba7 sconsbuild/Release/chrome So the text segment is 16.7MB. RefCounted.h:94 contributes to 2% of the code size. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Unit tests and anonymous namespaces.
2009/3/6 Scott Hess :
> I just wanted to make sure I understood your proposal.
>
> Right now, test classes want to be in the anonymous namespace so that
> unit test files do not have to coordinate with each other in the
> naming of test classes. With your proposal, the thing which is
> exposed outside of the anonymous namespace (MyClassPeer) is based on a
> thing already known to be unique (MyClass), so coordinate is not an
> issue unless you have multiple unit test files testing the same class.
> There are still just as many items exposed outside of the anonymous
> namespace, but they are named in a way which prevents collisions.
>
> Is that about right?
Mostly right. It's fewer things exposed outside of the anonymous
namespace, since previously you needed each TEST/TEST_F class to exist
outside the anonymous namespace in order for you to FRIEND_TEST it.
In this way, you only have one Peer per class you're testing. I don't
know enough about Chrome yet, but if there were some very commonly
used classes, then it might make sense to put the Peer class in a
header file for multiple tests to share. My gut instinct is this use
case doesn't happen enough in Chrome to make it worthwhile, but I have
no clue. It made more sense in the Google code base for various
reasons.
Also, I'm a big fan of testing via the public interface methods as
much as possible. Hopefully we don't need to friend most classes in
order to tell them well.
>
> Thanks,
> scott
>
>
> On Tue, Mar 3, 2009 at 4:49 PM, William Chan (陈智昌)
> wrote:
>> My old team never really used FRIEND_TEST. We found it ugly that our
>> production code depended on test code. We typically used friended
>> "Peer" classes defined in the unittest file, but not in the anonymous
>> namespace. These are simple shims that provide access to the private
>> section. It also saves on having to FRIEND_TEST each individual test
>> as you add them. It looks like almost every time FRIEND_TEST is used,
>> it's used for multiple tests, not just a single one. I'm not sure how
>> much of a problem chrome has with build dependencies leading to
>> rebuilds, but it was very annoying in google projects to add a
>> FRIEND_TEST to a widely used .h file, thus forcing everyone to
>> rebuild, even though you're only adding a new test.
>>
>> On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher wrote:
>>> On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess wrote:
>>>>
>>>> On the Mac, code like this:
>>>>
>>>> namespace {
>>>> class MyTest : public testing::Test {
>>>> };
>>>> } // namespace
>>>>
>>>> TEST_F(MyTest, ATest) {
>>>> }
>>>>
>>>> generates errors like this:
>>>> warning: 'MyTest_ATest_Test' has a field
>>>> 'MyTest_ATest_Test::' whose type uses the anonymous
>>>> namespace
>>>> warning: 'MyTest_ATest_Test' has a base '::MyTest' whose type
>>>> uses the anonymous namespace
>>>>
>>>> Removing the namespace fixes it, which is poor because we seem to want
>>>> to move towards more anonymous namespace use. Putting the test case
>>>> inside the namespace also fixes it, but is incompatible with
>>>> FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
>>>> http://gcc.gnu.org/gcc-4.2/changes.html
>>>>
>>>> "Members of the anonymous namespace are now local to a particular
>>>> translation unit, along with any other declarations which use them,
>>>> though they are still treated as having external linkage for language
>>>> semantics."
>>>>
>>>> At this point, I'm sort of at the bleeding edge of my knowledge. For
>>>> FRIEND_TEST() cases, it seems like the anonymous namespace needs to
>>>> go, but elsewhere it can be changed to enclose the entire file. Does
>>>> that seem reasonable for now?
>>>>
>>>> -scott
>>>
>>>
>>> Assuming that you really need to use TEST_F, then it would be unfortunate to
>>> lose the anonymous namespace. The anonymous namespace has allowed us to
>>> have short names for helper classes used by tests without fear of colliding
>>> with other short names used by other tests. (We have had those kinds of
>>> conflicts in the past.)
>>> We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
>>> to expose class APIs to unit tests?
>>> -Darin
>>> >>>
>>>
>>
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Unit tests and anonymous namespaces.
My old team never really used FRIEND_TEST. We found it ugly that our
production code depended on test code. We typically used friended
"Peer" classes defined in the unittest file, but not in the anonymous
namespace. These are simple shims that provide access to the private
section. It also saves on having to FRIEND_TEST each individual test
as you add them. It looks like almost every time FRIEND_TEST is used,
it's used for multiple tests, not just a single one. I'm not sure how
much of a problem chrome has with build dependencies leading to
rebuilds, but it was very annoying in google projects to add a
FRIEND_TEST to a widely used .h file, thus forcing everyone to
rebuild, even though you're only adding a new test.
On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher wrote:
> On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess wrote:
>>
>> On the Mac, code like this:
>>
>> namespace {
>> class MyTest : public testing::Test {
>> };
>> } // namespace
>>
>> TEST_F(MyTest, ATest) {
>> }
>>
>> generates errors like this:
>> warning: ‘MyTest_ATest_Test’ has a field
>> ‘MyTest_ATest_Test::’ whose type uses the anonymous
>> namespace
>> warning: ‘MyTest_ATest_Test’ has a base ‘::MyTest’ whose type
>> uses the anonymous namespace
>>
>> Removing the namespace fixes it, which is poor because we seem to want
>> to move towards more anonymous namespace use. Putting the test case
>> inside the namespace also fixes it, but is incompatible with
>> FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
>> http://gcc.gnu.org/gcc-4.2/changes.html
>>
>> "Members of the anonymous namespace are now local to a particular
>> translation unit, along with any other declarations which use them,
>> though they are still treated as having external linkage for language
>> semantics."
>>
>> At this point, I'm sort of at the bleeding edge of my knowledge. For
>> FRIEND_TEST() cases, it seems like the anonymous namespace needs to
>> go, but elsewhere it can be changed to enclose the entire file. Does
>> that seem reasonable for now?
>>
>> -scott
>
>
> Assuming that you really need to use TEST_F, then it would be unfortunate to
> lose the anonymous namespace. The anonymous namespace has allowed us to
> have short names for helper classes used by tests without fear of colliding
> with other short names used by other tests. (We have had those kinds of
> conflicts in the past.)
> We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
> to expose class APIs to unit tests?
> -Darin
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: linux async IO
2009/2/26 Dean McNamee : > Hey Will, > > I'd suggest as a first step improving the WorkerPool. It should be > pretty easy, I don't think it will hurt us to do something where we > fire off threads on demand, but then keep them around and reuse them. > Might need some timer to periodically destroy idle threads when we get > too many, etc. That's a pretty self contained change and would be a > good first review. After that it will make more sense to implement > the network file code to post tasks to the worker pool, and just do > blocking IO there. That sounds reasonable to me. > > Also, do you have some page cycler numbers now and some oprofile data? > I'd like to see the hot spots and where we are blocking on file > access. This will be great data for comparison to the async > implementation and make sure that we did indeed address all of the > places we were concerned about. Nope, I don't know if it runs yet. I think Darin told me that there was some bug on linux or mac or both where it fails to run. I'm not sure. I agree the data is useful. I'll see if I can get any numbers. > > Thanks > -- dean > > 2009/2/26 Craig Schlenter : >> On Wed, Feb 25, 2009 at 11:21 PM, Adam Langley wrote: >>> >>> On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) >>> wrote: >>>> I talked to Darin and he told me that this needs work since it's >>>> impacting the page cycler times, so I figured I'd pick it up. You >>>> have a TODO there saying to figure out how to best do async IO. Did >>>> you ever figure this out? I talked to Darin briefly and decided that >>>> the simplest thing to do for now is simply to post tasks to the global >>>> WorkerPool. The global WorkerPool linux implementation looks pretty >>>> silly and needs work, but it's probably good enough for the page >>>> cycler. How does this approach sound to you? >>> >>> It's not clear if you were considering using POSIX async IO on Linux >>> or not. Just in case you were: don't. It mostly doesn't work. >> >> LWN has a nice article on the future of async IO on linux here btw. >> >> http://lwn.net/Articles/316806/ >> >> Unfortunately that's not that useful currently. >> >> --Craig >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: linux async IO
Woops, newbie mistake, sent from my google.com addr the first time. 2009/2/25 William Chan (陈智昌) : > Sorry for not being clear. Yep, you're correct, I'm not planning use > POSIX async IO. Just planning to execute the sync IO on the > WorkerPool. > > On Wed, Feb 25, 2009 at 1:21 PM, Adam Langley wrote: >> On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) >> wrote: >>> I talked to Darin and he told me that this needs work since it's >>> impacting the page cycler times, so I figured I'd pick it up. You >>> have a TODO there saying to figure out how to best do async IO. Did >>> you ever figure this out? I talked to Darin briefly and decided that >>> the simplest thing to do for now is simply to post tasks to the global >>> WorkerPool. The global WorkerPool linux implementation looks pretty >>> silly and needs work, but it's probably good enough for the page >>> cycler. How does this approach sound to you? >> >> It's not clear if you were considering using POSIX async IO on Linux >> or not. Just in case you were: don't. It mostly doesn't work. >> >> AGL >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] linux async IO
Hey Dean, I talked to Darin and he told me that this needs work since it's impacting the page cycler times, so I figured I'd pick it up. You have a TODO there saying to figure out how to best do async IO. Did you ever figure this out? I talked to Darin briefly and decided that the simplest thing to do for now is simply to post tasks to the global WorkerPool. The global WorkerPool linux implementation looks pretty silly and needs work, but it's probably good enough for the page cycler. How does this approach sound to you? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
