On 10/03/2021 02:12, Jason Orendorff wrote:
> Hi, everyone.
>
> I'm pleased to announce that Jan De Mooij has agreed to take ownership of
> the JavaScript engine module.
>
> Following a Mozilla tradition that was venerable when I got here, Jan has
> been doing the job already for quite some
Il 04/03/2021 15.53, Carsten Grzemba ha scritto:
> Is there a recommendation for the gcc version to use for building the 78esr
> release?
You need GCC 7.1 or newer:
https://hg.mozilla.org/releases/mozilla-esr78/file/tip/build/moz.configure/toolchain.configure#l890
Gabriele
On 10/02/21 10:21, Henri Sivonen wrote:
> Chrome is moving to SSE3 as the unconditional baseline, which I
> personally find surprising:
> https://docs.google.com/document/d/1QUzL4MGNqX4wiLvukUwBf6FdCL35kCDoEJTm2wMkahw/edit#
>
> A quick and very unscientific look at Searchfox suggests that
>
[cross-posting to stability]
Hiya all,
this is a heads-up that we just landed a patch that rewrites the code we
use to write minidumps for content process crashes in Rust [1] for our
Linux builds. The resulting dumps should be identical to what we
obtained before, so if you spot strange crashes
Thanks for this work Simon, this is awesome!
There's also plenty of side effects to this that will make life better
for developers, just a few off the top of my mind:
- When sccache is in use files are preprocessed before being sent to
sccache, so even when hitting the cache we pay the price of
On 10/11/20 05:57, ISHIKAWA,chiaki wrote:
> Does this support split dwarf object files?
Not yet, but it should be possible to add support easily because the
crates we depend on for parsing DWARF debuginfo have just been updated
to support split DWARF [1].
Gabriele
[1]
[cross-posting to dev-platform]
Hello all,
I'm glad to announce that we switched our symbol scrapers for Linux
distributions to our new and improved Rust-based tooling [1]. This means
that when looking at crash reports or profiling you will not find stack
traces with missing or omitted function
On 27/10/20 21:18, Jim Mathies wrote:
> 3) Detect noticeable performance issues with page interaction and scrolling
> that normally don't occur, we'd appreciate bug reports with Firefox profiles.
Is the software fallback expected to use all available CPU cores/threads
for rendering? I enabled it
[cross posting to firefox-dev and stability]
Hello all,
the crash triage team needs your help in keeping Firefox stable! The
role of the triagers is to have a look at the crashes for a certain
version of nightly a few days after it has been released and file bugs
for crashes that haven't been
Hi,
this is probably not the right channel for this question, you might want
to ask on dev-f...@lists.mozilla.org or on the #b2g channel on Matrix.
Also there's no Firefox OS devices at the moment, but you can build a
B2G emulator using the latest mozilla-central tree. Let's follow up on
this on
On 06/05/20 17:01, Markus Stange wrote:
> I see. What about crashes during regular optimized builds? I'd hope
> those print stacks.
You mean local builds? Unless you have ac_add_options --enable-debug in
your mozconfig you won't see stack traces. What you can do in that case
is build with the
On 05/05/20 23:38, Nicholas Nethercote wrote:
> As for why that check is there... do opt builds produce any stack traces in
> tests? Normal assertions aren't enabled on opt builds, but
> diagnostic/release assertions are. I can't remember off the top of my head
> if they produce stacks traces in
Nicholas Nethercote rewrote the stack-fixing scripts we used to make
stack traces readable on automation in Rust. The resulting scripts are
two order of magnitudes faster leading to test runtimes being shortened
by up to 40 minutes <https://github.com/mozilla/fix-stacks/>.
- Gabriele Svelto
On 06/03/20 16:46, Andrew Sutherland wrote:
> Thank you both very much for the clarifications and your excellent work
> here!
>
> In terms of the Sentry crates, I presume that means the crates in
> https://github.com/getsentry/symbolic repo? Are there still reasons to
> use/pay attention to
Thanks a lot for doing this work Nicholas.
I would like to add that once this hits automation the perf and memory
usage improvements will have a measurable impact on the tests runtime.
That's because we feed the output of all our tests on automation to the
scripts, and if they hit even a single
Hi Andrew,
On 06/03/2020 01:27, Andrew Sutherland wrote:
> Does this eliminate the need documented at
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#stacks
> to acquire a `minidump_stackwalk` binary and then expose it via
> MINIDUMP_STACKWALK environment variable to get
[cross-posting to firefox-dev and stability]
We still have an open slot to triage crashes from Firefox nightly Monday
builds. This should take place on a Tuesday or a Wednesday. If somebody
has some spare cycles please shoot me a message or fill the roster entry
yourself here:
[cross-posting to dev-platform]
IPCError-browser | ShutDownKill crashes are the second most common ones
after OOMs and generally not actionable because we've been lumping
together a bunch of different stacks under the same signature.
These crashes represent a snapshot of a content process taking
[cross-posting to firefox-dev and stability]
FYI quite a few people followed up with me by mail and in person so the
roster will soon be full again but more volunteers are still welcome. If
we have more volunteers than the slots I'm very happy to do rotations so
that we have more eyes on nightly
[cross-posting to firefox-dev and stability]
Due to the recent layoffs the nightly crash triage roster has a lot of
holes so if you have some spare cycles please come and help out!
Nightly crash triage consists in looking at the crashes for a specific
version of nightly (e.g. the previous week
Hi all,
when dealing with builds on slower machines I usually run a build every
morning (4AM) so that when I wake up I've got it ready (together with a
warm cache) and following builds won't be as bad.
This can be done easily on a Mac by setting up a cronjob that will run a
build on a freshly
[cross-posting to dev-platform]
Hello all,
I just wanted to point out an excellent blog post by :willkg that
describes the whole crash reporting flow from the exception handler and
all the way to crash-stats.mozilla.com. You can find it here:
Hi Gangadharan,
On 22/03/19 05:25, gangadhara...@gmail.com wrote:
> I've been trying to build dav1d 0.2 but I always end with meson error
>
> Unusable script '/usr/bin/nasm'
> Program nasm found: NO
>
> meson.build:324:4: ERROR: Program(s) ['nasm'] not found or not executable
>
> Eventhough
Adding my 2p
On 19/02/19 17:54, Jason Orendorff wrote:
>> My understanding is that the original purpose is that if you in a loop
>> read from T* and write on each iteration via U* (where T and U differ
>> by more than signedness and neither is char), without
>> -fno-strict-aliasing the compiler
On 30/01/19 17:26, Mike Conley wrote:
> That's a good question. I haven't yet noticed any difference yet, but
> I'm hoping people can keep an eye out to see if there's appreciable lag
> when switching back to a tab with video, or if background audio starts
> to stutter.
>
> (I suspect that even
On 11/01/19 02:01, Ehsan Akhgari wrote:
> The common way to deal with this problem is to indent nested preprocessor
> directives, very much similarly to how we indent normal code, for example:
>
> #if foo
> # if bar
> #define x 1
> # else
> #define x 2
> # endif
> #endif
this would be
Hi all,
On 11/01/2019 01.24, Mike Hommey wrote:
> In the MSVC installer, choose the following extra components:
> - Visual Studio C++ compiler and libraries for ARM64
> - Visual C++ ATL for ARM64
> - Visual C++ MFC for ARM64
I don't have the MFC for ARM64 libraries installed and I didn't
On 06/12/18 15:39, Kris Maglione wrote:
> As it stands, we need to remain compatible with at least GCC and Clang,
> because some of our static analysis code still depends on GCC plugins.
Some Linux distros will keep building Firefox with GCC so there's going
to be at least some external users of
Hi Amirhossein,
On 06/11/2018 16.28, Amirhossein Ghafari wrote:
> 0:43.67 DEBUG: configure:3005: cl.exe -c -TP -nologo -w15038 -wd5026
> -wd5027 -Zc:sizedDealloc- -wd4091 -wd4577 -D_HAS_EXCEPTIONS=0 conftest.C 1>&5
> 0:43.67 DEBUG: conftest.C
> 0:43.67 DEBUG:
>
Hello all,
being among those unfortunate enough to have updated Visual Studio
before realizing that the most recent version cannot be used to build
Firefox, I was faced with the prospect of reinstalling the whole
monstrosity - which takes forever - or finding a workaround. As it turns
out I found
Bug 1348273 [1] just landed and with it how we deal with crash
annotations. All annotations are now declared in
toolkit/crashreporter/CrashAnnotations.yaml which contains both a
description, type and whitelisting/blacklisting information.
To add an annotation just add the entry to that list. By
Just another bit of info to raise awareness on a thorny issue we have to
face if we want to significantly raise the number of content processes.
On 64-bit Windows we often consume significantly more commit space than
physical memory. This consumption is currently unaccounted for in
about:memory
On 13/07/2018 04:55, Randell Jesup wrote:
> Correct - we need to have observers/what-have-you for
> background/foreground state (and we may want an intermediate state or
> two - foreground-but-not-focused (for example a visible window that
> isn't the focused window); recently-in-foreground
On 12/07/2018 22:19, Kris Maglione wrote:
> I've actually been thinking on filing a bug to do something similar, to
> measure cumulative effects of excess padding in certain types since I
> began looking into bug 1460674, and Sylvestre mentioned that
> clang-analyzer can generate reports on excess
On 19/06/2018 15:04, Sebastian Hengst wrote:
> TL;DR: We would like to change the mozilla-inbound backout policy to be
> like autoland’s.
Sounds like a very good idea. When I screw up with a patch what worries
me most is wasting other peoples' time with a broken tree. Having
problematic patches
On 13/04/2018 16:49, Nathan Froyd wrote:
> I lean towards the former here. I think the former is more common in
> the code I've seen, but apparently the latter is "preferred C++" or
> something?
Yes, let's have a solid rationale if we're doing sweeping changes of
this sort. Blindly following the
I've also seen TV failures caused by flaws in the test harness which
weren't visible before. See bug 1410165 [1] for example, it was caused
by an observer being unregistered after the first iteration of a test
had finished, causing the following iterations to fail.
Gabriele
[1] Permaorange
On 29/01/2018 10:54, Gijs Kruitbosch wrote:
> FWIW, this plan seems great to me. Thanks for taking the time to revise
> based on everybody's feedback!
You're welcome! When doing changes that touch the entire codebase I
believe it's critical to have everybody's feedback because it's
impossible to
Hello all,
I've tried to take into account all the suggestions from the discussion
of my previous proposal [1] and I've come up with a new plan which
should cover all bases. Don't hesitate to point out things that might
still be problematic, since this is going to be a large refactoring it's
On 04/01/18 22:47, Nathan Froyd wrote:
> This is very doable, it just requires some build system hackery: we
> accept preprocessed/generated WebIDL files, and generated IDL files
> would require basically the same approach. I can help with the build
> system hackery if you want to continue
On 04/01/18 22:39, Ben Kelly wrote:
> We can't have a comment explaining "please add any new constants in
> sequential order in the following list"?
We could, but what about removing one? Also if we have hundreds (or
thousands) the risk that one is accidentally duplicated is significant.
My
On 03/01/18 23:30, Ben Kelly wrote:
> Could we use our existing idl/webidl/ipdl for this? It would be nice
> not to have to maintain another code generator in the tree if possible.
AFAIK there is no way in IDL to declare an enum. Constants can be
declared but one needs to manually assign them a
TL;DR this is a proposal to refactor the observer service to use a
machine-generated list of integers for the topics (disguised as enums/JS
constants) instead of arbitrary strings.
Long version:
I've been working on bug 1348273 [1] in an attempt to gather all our
crash annotations into a
On 24/11/2017 05:18, Frank-Rainer Grahl wrote:
> Hi,
>
> I didn't see package-manifest changes in the bug.
>
> I assume this needs to stay in as-is?
Yes, when we build with --disable-crashreporter we still don't want the
various other bits (including the crash reporter UI) to be built and
[cross-posting to firefox-dev]
Fellow mozillians,
bug 1402519 [1] just landed and it introduces a dummy implementation of
the crash reporter which is built when configuring with
--disable-crash-reporter. This removes the need for bracketing calls to
the crash reporter with #ifdef
On 06/11/2017 22:44, Jeff Gilbert wrote:
> Price matters, since every dollar we spend chasing ECC would be a
> dollar we can't allocate towards perf improvements, hardware refresh
> rate, or simply more machines for any build clusters we may want.
And every day our developers or IT staff waste
On 04/11/2017 01:10, Jeff Gilbert wrote:
> Clock speed and core count matter much more than ECC. I wouldn't chase
> ECC support for general dev machines.
The Xeon-W SKUs I posted in the previous thread all had identical or
higher clock speeds than equivalent Core i9 SKUs and ECC support with
the
On 28/10/2017 01:08, Sophana "Soap" Aik wrote:
> Thanks Gabriele, that poses a problem then for the system build we have
> in mind here as the i9's do not support ECC memory. That may have to be
> a separate system with a Xeon.
Xeon-W processors are identical to the i9 but come with more
On 27/10/2017 01:02, Gregory Szorc wrote:
> Sophana (CCd) is working on a new system build right now. It will be based
> on the i9's instead of dual socket Xeons and should be faster and cheaper.
... and lacking ECC memory. Please whatever CPU is chosen make sure it
has ECC support and the
On 18/10/2017 10:28, David Teller wrote:
> I have one proposal. Could we change the behavior of the JS VM as follows?
>
> - The changes affect only Nightly.
> - The changes affect only mozilla chrome code (including system add-ons
> but not user add-ons or test code).
> - Any programmer error
On 09/10/2017 13:47, Henri Sivonen wrote:
> I omitted volatile, because the GCC manual said it has no effect on
> basic asm. However, it turns out it still has an effect on extended
> asm, which is what this is. Oops.
Yes, volatile implies the statement has side effects and so it cannot be
moved
On 06/10/2017 11:00, Henri Sivonen wrote:
> Do we already have a C++ analog of Rust's test::black_box() function?
> I.e. a function that just passes through a value but taints it in such
> a way that the optimizer can't figure out that there are no side
> effects. (For the purpose of ensuring that
On 28/08/2017 09:28, Erxin Shang wrote:
> I'm trying to build a release version Firefox. But after the build there
> seems still a little bit different compare to the official build. Such as the
> official build doesn't contain the folder chrome/, components/, gmp-fake/ etc
> in the root of
On 06/08/2017 21:56, Enrico Weigelt, metux IT consult wrote:
> For example, I'm currently working on making the whole wakelock
> stuff optional (eg. only built on android). Navigator.webidl
> references MozWakeLock, which wouldn't exist w/o wakelocks.
Do you mean navigator.requestWakeLock()?
On 05/07/2017 16:31, William Lachance wrote:
> We do run these tests in automation, you can track the results in
> perfherder under the platform_microbench framework:
>
>
On 14/07/2017 05:39, Boris Zbarsky wrote:
> I should note that with GitHub what this means is that you get
> discussion on the PR that should have gone in the issue, with the result
> that people following the issue don't see half the relevant discussion.
> In particular, it's common to go off
On 13/07/2017 01:06, Eric Rahm wrote:
> * *using breakpad* - was the problem that creating wrappers to access
> the c/c++ code was too tedious? Could bindgen help with that, if not
> it would be interesting gather some details about why it wouldn't
> work and file bugs against it.
On 10/07/2017 12:29, Nicholas Nethercote wrote:
> Hi,
> What are the obstacles? Here are some that I've heard.
> [...]
> Anything else?
In the past year I wrote two tools (minidump-analyzer and pingsender)
that ship with Firefox but are separate executables so both were good
candidates for being
On 24/03/2017 05:39, Gregory Szorc wrote:
> The introduction of Ryzen has literally changed the landscape
> and the calculus that determines what hardware engineers should have.
> Before I disappeared for ~1 month, I was working with IT and management to
> define an optimal hardware load out for
On 09/03/2017 22:35, Eric Rescorla wrote:
> I'm in favor of good commit messages, but I would note that current m-c
> convention really pushes against this, because people seem to feel that
> commit messages should be one line. Not sure what to do about that,
> but thought I would mention it.
On 08/03/2017 01:11, Mike Hommey wrote:
> You probably want a desktop machine, not a new laptop.
I second that, modern laptops are usually thermally limited. I actually
drilled holes in the back of my Thinkpad to improve airflow (and it did
improve build times).
My main box is a not-so-recent
On 07/02/2017 18:57, Gabor Krizsanits wrote:
> For a temporary workaround until we can speed up content process start up
> and initialization time, we might want to use the pre-allocated process
> manager for the e10s-multi case. Maybe even force to pick one from the
> existing processes unless
On 23/01/2017 18:44, Gian-Carlo Pascutto wrote:
> If only we had some crossplatform runtime that abstracted such system
> specifics away from us
> (https://bugzilla.mozilla.org/show_bug.cgi?id=663970) then maybe we
> wouldn't have to re-fix the same bugs every 5 years.
On this topic, I've heard
On 12/01/2017 09:05, Mike Hommey wrote:
> +1
>
> The sad part is that it's not followed enough.
The include hell [1] bug hasn't seem some action in a while. We might
set some time aside to do a bit of cleanup on the most commonly used
headers. I remember that the last time we did a significant
On 22/12/2016 19:14, Bobby Holley wrote:
> We've had this debate several times already, culminating in the attempt to
> ban NS_ENSURE_* macros. It didn't work.
If we don't want to get rid of it then why not make the intent
immediately obvious from the name? Something like MOZ_RETURN_IF_FAILED()
On 10/11/2016 18:12, smaug wrote:
> vsync handling happens usually right after a task (per HTML spec).
> Basically we have now two event queues with similar priority, and they
> are handled the same priority, but since
> the other one is used very rarely, events added to it get processed on
>
On 10/11/2016 00:22, smaug wrote:
> Parent process doesn't yet have higher priority handling [2].
> Need to fix racy tests first.
> Locally using higher priority also in parent process seems to make tab
> throbber smoother.
We have an ad-hoc mechanism for scheduling memory pressure event ahead
of
Replying to myself since nobody thought it worthwhile to reply and have
an open, honest discussion on this ML about this.
Parts of the gonk widget have already been removed; so the decision to
do it was taken was not communicated publicly. Or maybe it was never up
for discussion. I don't know
Hi Blake,
On 19/10/2016 00:28, Blake Kaplan wrote:
> I've been seeing a pattern of "unsafe" CPOWs causing our browser-chrome
> mochitests to go intermittently orange. Generally, it seems that a test
> randomly turns orange, gets starred and ignored until RyanVM or another one
> of our sheriffs
On 04/10/2016 01:22, Gregory Szorc wrote:
> https://dxr.mozilla.org/mozilla-central/search?q=gonk seems to
> contradict your assertion that gonk is well-contained.
I thought that the analysis in my first post was sufficiently detailed
but here's one with line numbers to get a more accurate idea:
> Respectively, it seems like these requests were ultimately not included
> in the final decision.
I would like to know why; I think that's not much to ask. I would also
like to know why this decision was made without any public discussion.
As I've pointed out the removal of another widget was
On 30/09/2016 06:04, Chris Peterson wrote:
> Is Gonk used anywhere besides B2G? Can we remove all Gonk code, e.g.
> dom/camera/Gonk* and #ifdef MOZ_WIDGET_GONK?
Gonk is not used anywhere else, some of it's code was merged with
Fennec's code to reduce the maintenance burden but there's still quite
Hello,
the non-standard SimplePush API provided a mechanism for Firefox OS to
receive push messages before the standard Push API was finalized. With
the standard Push API now implemented in Gecko and already enabled on
Android builds it should be easy to enable it on B2G too (see [1] if you
want
On 17/06/2016 16:57, Gerald Squelart wrote:
> From what *I* understand, RVO is guaranteed (or at least supported
> everywhere?) when there is only one stack variable that is returned, e.g.:
> C foo()
> {
> C rv;
> // ... (put stuff in rv)
> return rv;
> }
> In this case, the caller function
On 01/06/2016 15:20, Jonathan Kew wrote:
Does this suggest that we're not sufficiently proactive about firing
memory-pressure notifications, so that we'll free up memory from various
caches, etc? It looks like we regard 128MB of available VM as "low" (see
[1]) on Windows 32-bit, but apparently
On 31/05/2016 13:26, Gijs Kruitbosch wrote:
> We could do a find/replace of no-arg calls to a new macro that uses
> MOZ_CRASH with a boilerplate message, and make the argument non-optional
> for new uses of MOZ_CRASH? That would avoid the problem for new
> MOZ_CRASH() additions, which seems like
On 31/03/2016 07:42, Kyle Huey wrote:
> I'll pose to you the same question I posed bsmedberg, is this actually
> worth fiddling with all the existing runnables.
I did some testing around a couple of years ago and the answer is the
same as usual: it depends. On modern x86 machines I doubt one
On 15/03/2016 04:34, Nicholas Nethercote wrote:
> - "heap-overhead" is 4 MiB per process. I've looked at this closely.
> The numbers tend to be noisy.
>
> - "page-cache" is pages that jemalloc holds onto for fast recycling. It is
> capped at 4 MiB per process and we can reduce that with a
On 13/03/2016 09:22, Kyle Huey wrote:
> Much of the "disease" you see is simply support for DOM worker threads,
> because every runnable that can run on those threads must be
> cancelable. Workers do not guarantee one of the invariants that other
> XPCOM threads do: that every runnable is
Many moons ago, while we were frantically trying to make Firefox OS 1.0
run half-decently, I introduced a derived class of nsIRunnable that
could be canceled: nsICancelableRunnable. As with many other things that
led to the first release of FxOS this was done in a rush and without
much thinking.
On 26/01/2016 10:51, jma...@mozilla.com wrote:
> I would assume all gecko patches would get landed on either mozilla-inbound
> or fx-team. If you use mozreview and take advantage of the autoland feature,
> then these specific patches will land on mozilla-inbound.
Thanks, I'll definitely have a
On 26/01/2016 10:19, Shawn Huang wrote:
> Hi Fabrice,
> Following this comment, I'm confused. Do we need to check-in into
> b2g-inbound by hand? "checked-in" keyboard no longer supports FirefoxOS
> project? Does this mean only people who have Level 3 access permission can
> land code?
Same here.
On 2015-07-24 7:37 AM, Meenakshi Shankar wrote:
We are using Firefox SDKS for our FF extension (libs generated after
compiling Firefox 40 beta 4 source using start-shell-msvc2013). As
there are some differences between Firefox 39 and Firefox 40 binaries,
instead of mozalloc.lib , the
On 07/07/2015 05:12, Jeff Gilbert wrote:
Notable works or style guides [2] which do not recommend `aFoo`: [3]
[...]
To add another internal datapoint the FxOS gaia codebase is mostly
devoid of this style. There are some places using the m prefix for
pseudo member variables (really just JS
On 21/04/2015 08:25, Gabor Krizsanits wrote:
Maybe because I usually work on core, and such confidence is hard to reach
there, but I'd like to think at least a try run that check if the patch
builds on all platform and a full test run on at least one platform is not
too much sacrifice of ones
On 01/02/2015 13:18, Howard Chu wrote:
People may say I'm biased since I'm the author of LMDB but I have only
ever posted objective, reproducible comparisons of LMDB to other
alternatives. http://symas.com/mdb/#bench
If your typical record sizes are smaller than 1KB and you have more
writes
On 30/01/2015 08:45, Jonas Sicking wrote:
However, it would be cool if we fixed our IndexedDB implementation
rather than told our own developers not to use it. Web developers are
not so lucky as to have other options.
Yeah and we're making some pretty heavy use of it within Firefox OS.
I've
On 27/10/2014 08:08, Karl Dubost wrote:
2. It seems to be a change of policy in terms of sharing data the user type
in the URL bar. Is there a possibility to put that off and not having
whatever you type up there to be sent somewhere the user does not expect?
Yes, suggestions can be disabled
On 27/10/2014 09:55, Karl Dubost wrote:
1. Being usability (performance on flickering) Bug number?
We've got bug 1027381 [1] though we might want to introduce a mechanism
to also throttle the requests we send (and drawing the spinner which
takes a huge amount of CPU time slowing down the user).
On 17/10/2014 00:32, Nicholas Nethercote wrote:
Thanks for the replies so far! I deliberately left this question vague
to see what kind of responses people would give. But mostly I'm
interested in code whose awfulness impacts users in a serious way.
Ones where refactoring/rewriting efforts
Having previously worked on a couple of GCs I must say this is amazing
work! I don't know many other large, complex code bases such as Gecko
that were moved successfully from a conservative mark-and-sweep
collector to an accurate generational one. Bravo to everyone involved!
Gabriele
On
On 19/07/2014 22:40, Ralph Giles wrote:
Probably not for Firefox OS, if you mean mozjpeg. Not necessarily
because it uses hardware, but because mozjpeg is about spending more cpu
power to compress images. It's more something you'd use server-side or
in creating apps. The phone uses
On 14/07/2014 15:33, Ehsan Akhgari wrote:
2. Can we get a field designating the creation of bugs, so that I can
set things up so that I get bugmails for new bugs no matter what?
+1 for that. One thing I always do is check for new bugs in the
components I'm watching and then CC me on those of
On 30/05/2014 14:19, Andreas Gal wrote:
Now for Intel hardware being slow there could be a couple reasons, and APZ
might fix them actually. If I remember correctly Atom GPUs are PowerVR based,
which is a tile based rendering architecture. It splits the frame buffer in
small tiles and
This morning I've been asked to do a review for bug 980027 [1] mostly
because I've been working actively on that code and I did some small
reviews in the past. Since the change was relatively large this time
I've asked the patch author to ask a review from a Hal peer in addition
to me which lead
On 07/04/2014 23:13, Dave Hylands wrote:
Personally, I think that the more ways we can test for threading issues the
better.
It seems to me that we should do some amount of testing on single core and
multi-core.
Then I suppose the question becomes how many cores? 2? 4? 8?
Maybe we can
On 20/02/2014 18:57, arpad.bor...@googlemail.com wrote:
And yes, allocation counts would be awesome. Any idea how to get to those? Or
even better: number of average live objects, since short lived allocations do
not matter that much.
Just thinking out loud: some memory reporters should
On 03/12/2013 22:30, Jed Davis wrote:
At the risk of stating the obvious, localizing the size change should
be a simple matter of `readelf -WS`. If we're seeing actual change
in .text size by way of per-directory sort-of-LTO, then that would be
interesting (and could be localized further with
On 28/11/2013 10:57, Neil wrote:
I often build in a VM. I allocate 2 CPUs and 2GB of RAM to it, which
seems to be enough even to link xul.dll with debug symbols, although it
takes a few minutes. (Linking it without symbols takes just seconds.)
Given the amount of memory needed to link I haven't
On 28/11/2013 06:06, Gregory Szorc wrote:
On de5aa094b55f, we're now down to:
Wall 7:37 (457)
User 45:38 (2738)
Sys3:54 (234)
Total 49:32 (2972)
That's with WebRTC and ICU enabled.
Looking at my own stats while building I was wondering if anybody has
looked at peak memory
1 - 100 of 113 matches
Mail list logo
