Re: Replacing gcc 4.5 as the default Linux compiler?
On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote: > FYI: Upgrading binutils to 2.23.2 did not help. > (Well, at least I got a better memory usage report when > memory was exhausted. "ld" printed out that it fails to allocate this many > bytes after having allocated the total amount. They are printed numerically. > It was close to 1GiB and so I assumed it is hitting some 32-bit linux limit > (my linux kernel is PAE kernel.) > > Downgrading to gcc-4.6 and g++-4.6 helped. > Specifying gcc-4.6 and g++-4.6 explicitly during configure, > I could compile TB and run test again. Try gold with gcc 4.7. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing gcc 4.5 as the default Linux compiler?
FYI: Upgrading binutils to 2.23.2 did not help. (Well, at least I got a better memory usage report when memory was exhausted. "ld" printed out that it fails to allocate this many bytes after having allocated the total amount. They are printed numerically. It was close to 1GiB and so I assumed it is hitting some 32-bit linux limit (my linux kernel is PAE kernel.) Downgrading to gcc-4.6 and g++-4.6 helped. Specifying gcc-4.6 and g++-4.6 explicitly during configure, I could compile TB and run test again. Hope this helps. On (2013年04月02日 20:01), ishikawa wrote: > On (2013年04月02日 13:58), ishikawa wrote: >> On (2013年04月02日 13:52), ishikawa wrote: >>> [I just noticed that in a follow-up post that LTO pass requires 6GB of >>> memory on 64bits linux, >> >> Ooops: A typo of my own: it was not *6*GB but *3*GB in the GCC note. >> >> But funny, the ld seems to give up hands immediately now >> (a few days ago, it tried to use up memory space by using swap and all that. >> Something has changed.) >> > > I think the problem I am seeing with TB build may be a different issue. > > Come to think of it, I have been using -O for optimization since > I want to run the DEBUG BUILD of TB under valgrind/memcheck. > (So it should not run PGO, correct?) > > An explicit method to disable PGO just in case will be appreciated. > Is it as follows? > > mk_add_options MOZ_PGO=0 > > > I suspect that libxul.so link now tries to accept more objects (maybe, pure > guess) and is choking for new TB build framework. > > Anyway I will check > - if newer "ld" solves the issue, or > - downgrading to gcc 4.6 will help. > > > > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink meeting: Today April 2, 2013 @ 4:00pm PDT
Today's MemShrink meeting will be brought to you by zones, a.k.a. compartment groups: https://bugzilla.mozilla.org/show_bug.cgi?id=759585 NOTE: new meeting time, new vidyo room The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Discuss results of Zones landing. * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, April 2, 2013, 4:00 PM PDT * Vidyo Room: SFO 7J Justice League * Physical Rooms: Justice League, San Francisco office, 7th floor. Very Good Very Mighty, Mountain View office, 3rd floor. * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 95749 -- Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
End of life for tinderbox.mozilla.org
As soon as the last dependency on bug#843383 is closed, we're planning to power off the tinderbox.m.o server here at Mozilla. This should be a non-event, as Firefox, Fennec, B2G, Thunderbird, SeaMonkey, Camino, NSS and l10n are all no longer using tinderbox. However, if you know of anyone who is still using tinderbox.m.o, or you know of a reason to keep tinderbox server alive, please add that info to bug#843383 asap. Exact switchoff date depends on closing the remaining blocker depbugs, but it'll be measured in days/weeks, not months. I'll post again at that point. NOTE: This announcement is *only* about decommissioning tinderbox.m.o. Obviously, the "new" tbpl.m.o will continue in full production use, but I wanted to be explicit to avoid any confusion/concerns. If you've any questions/comments, please add them in the bug, or email me directly. Thanks John. = (Sorry for the cross-postings, but this is important to make sure everyone sees. Please respond, or ask questions, in bug#843383.) signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Awesome "Quantile" Telemetry Plots on metrics.mozilla.com
https://bugzilla.mozilla.org/show_bug.cgi?id=699670 On Tue, Apr 2, 2013 at 11:58 AM, Patrick McManus wrote: > Today I noticed some (relatively) new CDF plots of telemetry histogram > data on metrics.mozilla.com. Maybe in the last week or so? > > This makes it much easier to determine medians and 90th percentiles - > which is a very common use case for me. If you haven't seen it I > recommend checking it out. > > If, dear reader, you are responsible then thank you! I didn't know who to > thank. > > -Patrick > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Awesome "Quantile" Telemetry Plots on metrics.mozilla.com
Today I noticed some (relatively) new CDF plots of telemetry histogram data on metrics.mozilla.com. Maybe in the last week or so? This makes it much easier to determine medians and 90th percentiles - which is a very common use case for me. If you haven't seen it I recommend checking it out. If, dear reader, you are responsible then thank you! I didn't know who to thank. -Patrick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Adjusting Windows 64-bit per-checkin builds (not related to nightly builds)
On 2013-03-27 1:29 PM, Benjamin Smedberg wrote: On 3/27/2013 1:19 PM, Armen Zambrano G. wrote: On another note, there could be a tree booked for win64 and move nightly win64 users there (orthogonal to updating users to 32-bit builds) since it would allow the community control which merges from mozilla-central to take in (and back out from bad merges). We could have dep builds running on it as well as on mozilla-central [1][2]. Please let me know what you think of this second part of the post. I don't think that an extra would be necessary or useful. So far, nobody has volunteered to maintain the win64 port, so having an extra tree only means that nobody would do merges and we wouldn't even have nightly regression ranges when things broke. --BDS I believe alex_mayorga volunteered on the "update on turning off 64-bit" thread. Makoto Kato might be interested as well. We have try support if anyone wants to fix issues. best regards, Armen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Adjusting Windows 64-bit per-checkin builds (not related to nightly builds)
Since last Friday, we're only running win64 builds per check-in on [1]: * mozilla-central * try [2] We generate nightly win64 updates on mozilla-central. All win64 jobs are running hidden: https://tbpl.mozilla.org/?jobname=WINNT%206.1%20x86-64&showall=1 Our win32 builds are now not seeing delays to be processed. best regards, Armen [1] https://bugzilla.mozilla.org/show_bug.cgi?id=814009 [2] trychooser has been updated and this is the syntax: "try: -b o -p win64 -u none -t none" On 2013-03-27 1:19 PM, Armen Zambrano G. wrote: Hi, We're currently suffering lack of capacity on the win64 builders. I noticed that we still run win64 dependent builds for Thunderbird & Firefox. I would like to disable those since they cost approximately 1/3 of our load (win32 opt/debug & win64 opt). ... best regards, Armen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Test harness preferences moving out of automation.py
tl;dr - If you update a test harness pref in build/automation.py.in, please also update it in testing/profiles/prefs_general.js. This is temporary and I am working to remove the automation.py.in location in bug 830430[1] --- Currently prefs that are common to our test harnesses are hardcoded in a string of Javascript inside of automation.py. This is bad for many reasons: 1) It isn't obvious to find - as a result prefs for various harnesses have been littered throughout the tree 2) Most of the newer harnesses don't use automation.py - these have no way of taking advantage of these prefs and must duplicate them 3) Storing Javascript in a python string and writing to a file is just yucky in general - it should start out in a js file Instead we have decided to create a single canonical directory that will store all prefs (and other profile information). This location is testing/profiles. So, if you update a test harness pref in build/automation.py.in, please also update it in testing/profiles/prefs_general.js. Having two locations for prefs is bad, and I'm working to remove the automation.py location in bug 830430[1]. I'll make sure the two locations are in sync before doing so. If you have any questions, concerns or suggestions feel free to contact me or post in the bug. Thanks, Andrew [1] https://bugzilla.mozilla.org/show_bug.cgi?id=830430 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing gcc 4.5 as the default Linux compiler?
On (2013年04月02日 13:58), ishikawa wrote: > On (2013年04月02日 13:52), ishikawa wrote: >> [I just noticed that in a follow-up post that LTO pass requires 6GB of >> memory on 64bits linux, > > Ooops: A typo of my own: it was not *6*GB but *3*GB in the GCC note. > > But funny, the ld seems to give up hands immediately now > (a few days ago, it tried to use up memory space by using swap and all that. > Something has changed.) > I think the problem I am seeing with TB build may be a different issue. Come to think of it, I have been using -O for optimization since I want to run the DEBUG BUILD of TB under valgrind/memcheck. (So it should not run PGO, correct?) An explicit method to disable PGO just in case will be appreciated. Is it as follows? mk_add_options MOZ_PGO=0 I suspect that libxul.so link now tries to accept more objects (maybe, pure guess) and is choking for new TB build framework. Anyway I will check - if newer "ld" solves the issue, or - downgrading to gcc 4.6 will help. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
