> - Remove all conditional feature configuration from configure. WebRTC et al
> are always
> on. Features should be disabled dynamically (prefs), if at all.
Note that Fabrice has seen sizable memory-usage wins on B2G by
disabling non-web features such as printing and XUL. That alone is,
in my
On Tue, Aug 6, 2013 at 5:46 PM, Robert O'Callahan wrote:
> I was talking to people about plans for Flash on e10s.
>
> Full support for windowed Flash on e10s is possible but would be a ton of
> work. Flash is on a downward trajectory and it would be a shame to do a ton
> of work to support somethi
Nick, when you made changes to the JS engine's #includes, did you
observe a change in build times?
On Sat, Aug 3, 2013 at 1:14 AM, Nicholas Nethercote
wrote:
> On Sat, Aug 3, 2013 at 5:47 PM, Mike Hommey wrote:
>>
>> One piece of the puzzle, at least in Mozilla code, is the tendency to
>> #inclu
On Sun, Aug 4, 2013 at 8:15 AM, Robert Kaiser wrote:
> Mark Hammond schrieb:
>
>> We ask the docShell to not allow plugins or media
>
> So that means that for any page with a video or a big Flash/Java thing on
> it, I would get a completely wrong thumbnail? That's unfortunate.
It's a lot better t
> I agree that iostream-based logging would be safer. If we had it I
> wouldn't have had to work on this one:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=855335
I can't access that bug, but maybe you mean
https://bugzilla.mozilla.org/show_bug.cgi?id=onelogger ?
I feel like the goals there a
On Thu, Aug 1, 2013 at 6:50 PM, Nicholas Nethercote
wrote:
> On Thu, Aug 1, 2013 at 6:29 PM, Gavin Sharp wrote:
>>
>> Do you have specific issues you're worried about, or are you just speaking
>> about issues in general?
>
> This AdBlock issue worries me specifically. And the fact that there's
>
erms of saving disk
space.
On Wed, Jul 31, 2013 at 5:57 PM, Mike Hommey wrote:
> On Wed, Jul 31, 2013 at 10:28:38AM -0700, Justin Lebar wrote:
>> >> Wouldn't switching branches in the same repo clone touch many files
>> >> and trigger unfortunately clobber builds? Eve
> 1. How much, and where, should we be using standard C++ library
> functionality in Mozilla code?
We've tuned tarray, nsthashtable, strings, etc. to meet our precise
needs, and the implementations are consistent across all platforms.
I can imagine things becoming quite messy we had three or four
>> Wouldn't switching branches in the same repo clone touch many files and
>> trigger unfortunately clobber builds? Even with ccache and separate
>> per-branch objdirs, this seems like a problem.
>
> Yes.
Nothing about this proposal forces you to have only one clone and
switch back and forth betwe
> Just to be clear though, if I find they are *not* all being removed, I
> should open a bug on that rather than just removing the listeners myself and
> calling it done? ie, is it accurate to say that it *should* not be
> necessary to remove these handlers (and, if I verify that is true, that I
>
Thanks for asking about this; we have a lot of unnecessary unlinking
code in our JS,
Let me share how I investigated your question.
$ git grep -i addmessagelistener -- '*.cpp'
content/base/src/nsFrameMessageManager.cpp:nsFrameMessageManager::AddMessageListener(const
nsAString& aMessage,
Only one
> As I understand it this is the case. From Mark's original post:
Ah, thanks. I missed that whole paragraph.
With some simple Gecko patches, we could pretty easily control which
process an iframe gets allocated into, so going down that route sounds
sane to me.
Alternatively, if you made the fra
> Poking around, I discovered bug 806127, where jlebar struck the same basic
> problem for b2g, which gave me the
> clue for a work-around. If I grab the docShell for this frame and execute:
>
> docShell.setIsBrowserInsideApp(Ci.nsIScriptSecurityManager.NO_APP_ID);
You should check, if you have
> It seems really dangerous that there is an implicit conversion from a strong
> ref ptr to a weak pointer. With C++11, you can thankfully require this
> conversion to be explicit which should alleviate your concern.
Wouldn't disallowing this implicit conversion break code which does
void UseFo
AIUI the new constructor would be something like
nsRefPtr(nsRefPtr&& aOther)
where "&&" means "r-value", which means "temporary", so "moveable".
But I'm not totally sure about being able to return nsRefPtr.
Right now, if I do
already_AddRefed GetFoo();
Foo* foo = GetFoo();
that's a comp
>> Maybe we should call ours mozilla::move and mozilla::forward so that we
>> can change to std::move and std::forward with minimal pain?
>>
> Won't that cause confusion if someone accidentally has both using namespace
> mozilla; and using namespace std; at the same time?
That's a fair point. May
Maybe we should call ours mozilla::move and mozilla::forward so that we can
change to std::move and std::forward with minimal pain?
On Jul 19, 2013 4:36 PM, "Ehsan Akhgari" wrote:
> On 2013-07-19 7:04 PM, Mike Hommey wrote:
>
>> On Fri, Jul 19, 2013 at 03:45:13PM -0400, Ehsan Akhgari wrote:
>>
>>
The flip side of this, of course, is that build peers need to ensure
that they are not the long pole in reviews. But I presume you guys
are prepared to turn around these additional reviews quickly,
otherwise you wouldn't have asked for the extra load.
On Wed, Jul 17, 2013 at 5:00 PM, Gregory Szor
> We can't require any c++11 feature until we drop support for gcc 4.4.
> [...] there are problems in the gcc 4.4 system headers that make using c++11
> mode impossible (except on b2g/android).
Is there any reason to support gcc 4.4 outside of B2G/Android?
If we dropped support for gcc 4.4 on de
> I may still be missing something, but afaict mq < git rebase -i < hg
> qcrecord (from the crecord extension.) This is speaking as someone who
> hasn't used git rebase -i much, but people who have seem to agree with me
> after seeing a qcrecord/qcrefresh demo.
qcrecord is, as far as I'm aware (it
re you rebased. This is in contrast to hg, where |hg qref| is
destructive and can cause you to lose work (unless you're versioning
your patch queue, which is a whole other can of worms).
On Wed, Jul 10, 2013 at 6:49 PM, Chris Peterson wrote:
> On 7/10/13 3:01 PM, Justin Lebar wrote:
>>
2013 at 3:08 AM, Robert O'Callahan wrote:
> On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar
> wrote:
>>
>> If I can propose something that's perhaps different:
>>
>> 1) Write software to figure out who's "slow with reviews".
>> 2) We t
One definition of insanity is doing the same thing twice and expecting
different results.
I recall that Taras has written basically this same e-mail before. We
seem to have this conversation every six months or so. Why do we
expect different results this time?
If I can propose something that's
On Fri, May 31, 2013 at 4:07 PM, Matt Brubeck wrote:
> On 5/31/2013 12:32 PM, Boris Zbarsky wrote:
>>
>> On 5/31/13 3:20 PM, Matt Brubeck wrote:
>>>
>>> blame mobile/android/chrome/content/browser.xul:
>>>git 1.015s
>>>hg 0.830s
>>
>>
>> Was this a git blame -C (which would be more simila
> I can't see how they are a good alternative. With patch queues, I can
> maintain a complex refactoring in a patch queue
> containing dozens of smallish patches. In particular, I can easily realize I
> made a mistake in patch 3 while working on patch
> 21 and make sure that the fix ends up in pa
On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch wrote:
> I also agree to Randell and Joshua. I've been using both lately and there
> are just a few things missing in git that I am used to in hg.
>
> Mercurial Queues is the most prominent. I am used to switching the order of
> patches in my queue,
push. There's no difference between
them.
Sorry for the confusion!
On Fri, Jun 28, 2013 at 7:07 PM, Kyle Huey wrote:
> On Fri, Jun 28, 2013 at 7:04 PM, Justin Lebar
> wrote:
>>
>> tl;dr - Changes from bug 820686:
>>
>> 1. We renamed MOZ_NOT_REACHED to MOZ_ASSU
tl;dr - Changes from bug 820686:
1. We renamed MOZ_NOT_REACHED to MOZ_ASSUME_UNREACHABLE.
2. In Gecko, please use MOZ_CRASH instead of MOZ_NOT_REACHED unless you care
about code size or perf.
3. In JS, we removed JS_NOT_REACHED in favor of MOZ_ASSUME_UNREACHABLE.
4. Don't put code after MO
Under what circumstances would you expect the code coverage build to break
but all our other builds to remain green?
On Jun 24, 2013 6:51 PM, "Clint Talbert" wrote:
> Decoder and Jcranmer got code coverage working on Try[1]. They'd like to
> expand this into something that runs automatically, gen
> On a different gear, would we want to keep m-c/m-i/projects etc. as separate
> git repos, or could we make them branches in a merged repo?
Many hours of sleep have been lost fighting over the answer to this
question -- the debate lasted for almost a year., with strong
advocates on both sides.
> For example, a public method (which we want to test in the unit test) has a
> number of side effects, but we don't have the public accessors to examine all
> of those private side effects/state.
I had this problem with the B2G process priority tests.
>From a mochitest, I wanted to create a va
This is only tangentially on topic, but I have a git pre-commit hook
which detects .orig files and trailing whitespace. It's saved me a
lot of embarrassment.
I also have a git tool which will fix trailing whitespace in your patch.
https://github.com/jlebar/moz-git-tools#pre-commit
https://github
he backend/ datastore.
>
> Regardless, doing Github integration in BugzillaJS should be trivial.
>
> Mike.
>
> On May 24, 2013, at 4:50 PM, Justin Lebar wrote:
>
> * I think we should experiment (again) with real pull-request integration
> into bugzilla.
>
>
> I&#
> * I think we should experiment (again) with real pull-request integration
> into bugzilla.
I'm totally in favor of better tools and real pull requests, and of
course the PRs need to be linked to bugzilla /somehow/.
But I want to qualify "integration into bugzilla": I explicitly do not
want a to
> I believe roc proposed just having an explicit hard coded list of things
> to start up a while ago, and I'm tempted to say that's what we should do for
> shutdown too. So just add an explicit call to some os.file thing
> followd by a call to a telemetry function after profile-before-change
> but
If we wanted to check out the RC from svn, is that trunk, or is it one
of the branches? It's not really clear how the SVN repo is set up, or
how to check out the right rev for llvm + clang.
http://llvm.org/svn/llvm-project/llvm
http://llvm.org/svn/llvm-project/cfe
On Fri, May 10, 2013 at 12:51 P
Four points here.
1. We're assuming that MathJax is as good with MathML as it is without
it, but perhaps we could ask the MathJax folks to comment on whether
this is true. I'd certainly be a lot more comfortable dropping MathML
if the MathJax folks said there was no point.
2.
> A suitable subse
See https://bugzilla.mozilla.org/show_bug.cgi?id=809430#c39 for details.
As roc points out, this has broken |mach build |. Stay tuned in
the bug if you're interested in whether we resolve this by backing out
the change or fixing mach.
-Justin
___
dev-p
> Given the whole point of this thread is about how unreliable inbound is, why
> are people trying to develop against it?
You still need a copy of inbound to rebase your patches against when pushing.
Whatever your personal opinions about git happen to be, I don't think
a "git doesn't need a copy
> Is there sanity to this proposal or am I still crazy?
If we had a lot more project branches, wouldn't that increase the load
on infra dramatically, because we'd have less coalescing?
This is of course a solvable problem, but the fact that the problem
exists suggests to me that your proposal her
> 3/ Being a git guy, I prefer having a try-like server where you don't get
> push contention or closed tree, because we are creating a new head
> every-time, and let the sheriffs cherry-pick the good changes which are not
> source of conflicts. And ask developers to rebase their changes otherwise
> If I have a patch ready to land when inbound closes, what would be the
> sequence of steps that I need to do to land it on inbound2? Would I
> need to have an up-to-date inbound2 clone and transplant the patch
> across?
Yes, I think so.
I think mbrubeck or someone knows how to maintain multipl
I like that inbound2 would be open only when inbound is closed. That
way you don't have to make a decision wrt which tree to push to.
sgtm.
On Fri, Apr 26, 2013 at 3:17 PM, Ryan VanderMeulen wrote:
> As has been discussed at length in the various infrastructure meetings, one
> common point of f
> The current level of flakiness in the IndexedDB test suite (especially on
> OSX) makes me concerned about what to expect if it starts getting heavier
> use across the various platforms.
Is that just in the OOP tests, or everywhere?
___
dev-platform mai
'm happy to disable just m-i/try for now.
>
> Modifying to trigger *some* jobs on m-i through would be some decent amount
> of work (adding Mac pgo builders) but still different than normal operations
> and increase the 10.6/10.8 test load.
>
>
> On 2013-04-26 1:31 PM, Justi
6, 2013 at 1:03 PM, Armen Zambrano G. wrote:
>
> On 2013-04-26 12:14 PM, Justin Lebar wrote:
>>>
>>> Would we be able to go back to where we disabled 10.7 altogether?
>>
>>
>> On m-i and try only, or everywhere?
>
>
> The initial proposal was
f Mac
>> as is without bringing 10.9 into the table. We have to cut things at
>> times.
>>
>> One compromise that would be easy to implement and *might* reduce the
>> load is to disable all debug jobs for 10.7.
>>
>> cheers,
>> Armen
>>
>&
013 11:11 AM, Justin Lebar wrote:
>>>
>>> So what we're saying is that we are going to completely reverse our
>>> previous tree management policy?
>>
>>
>> Basically, yes.
>>
>> Although, due to coalescing, do you always have a full ru
> So what we're saying is that we are going to completely reverse our
> previous tree management policy?
Basically, yes.
Although, due to coalescing, do you always have a full run of tests on
the tip of m-i before merging to m-c?
A better solution would be to let you trigger a full set of tests
> If apps are served from and signed by the marketplace, then any origin is
> okay (after
> review.)
I know that we rely on code review for a lot of security assurance
questions, but it seems to me that allowing /any origin/ opens us up
to attacks needlessly.
Could we allow any out of a whitelis
Sorry, I must have misunderstood what you meant.
If all you're saying is that sometimes, it's good to call a meeting to
make a decision, I don't think we disagree.
On Thu, Apr 25, 2013 at 4:56 PM, Milan Sreckovic wrote:
>
>
> On 2013-04-25, at 2:07 PM, Justin Lebar wro
sparnian
wrote:
> On 2013-04-25 2:39 PM, Justin Lebar wrote:
>>>>
>>>> We could come to the compromise of running them on m-c, m-a, m-b and
>>>> m-r. Only this would help a lot since most of the load comes from m-i and
>>>> try. We could make
many 10.7 machines do we operate in that pool?
>> >
>> > Andreas
>> 84 of them are 10.6
>> 86 of them are 10.7
>>
>> Unfortunately, we have a lot of them down (maybe a dozen) trying to fix them
>> (broken hard drives, bad memory, NIC). They don&
icular topic.
>
> The time zone mess is, well, a mess. Not much that can be done about it in
> general. When there is a decision making meeting that you can't attend, get
> yourself a proxy, make sure somebody understands your stand, and hopefully
> they can make the meeting an
It would be nice if we had data indicating how often tests fail on
just one version of MacOS, so we didn't have guess how useful having
10.6, 10.7, and 10.8 tests are. That's bug 860870. It's currently
blocked on treeherder, but maybe it should be re-prioritized, since we
keep running into cases
e than happy to assist you guys in narrowing things down to
fewer choices.
On Thu, Apr 25, 2013 at 10:27 AM, Chris AtLee wrote:
> On 01:48, Thu, 25 Apr, Justin Lebar wrote:
>>>
>>> One idea might be to give developers feedback on the consequences of a
>>> particular
> One idea might be to give developers feedback on the consequences of a
> particular push, e.g. the AWS cost, a proxy for "time during which
> developers couldn't push" or some other measurable metric. Right now
> each push probably "feels" as "expensive" as every other.
For tryserver, I propose
One thing I love about the MoCo meetings is that if I don't go, I
don't miss anything except the chance to ask questions: mbrubeck &co
create detailed minutes (really, transcripts) of every meeting, which
I can read on my schedule. He then e-mails the transcript out to
everyone, so I don't even ha
To close the loop on this thread, the consensus here seems to be that
1. We should continue to make JS slimmer. This is a high priority for
B2G even setting aside the memory consumption of B2G's chrome JS,
since of course B2G runs plenty of content JS.
The memory profile of B2G is different from
As Jono would say,
it's not the user's fault.
On Tue, Apr 23, 2013 at 12:50 AM, Justin Lebar wrote:
>> The ratio of things landed on inbound which turn out to busted is really
>> worrying
>
>> * 116 of the 916 changesets (12.66%) were backed out
>
> If 13% is &
> The ratio of things landed on inbound which turn out to busted is really
> worrying
> * 116 of the 916 changesets (12.66%) were backed out
If 13% is "really worrying", what do you think our goal should be?
On Tue, Apr 23, 2013 at 12:39 AM, Ehsan Akhgari wrote:
> This was a fantastic read, it
> This is all great stuff, but as mentioned elsewhere, B2G branched at
> version 18 and so they need improvements that that can land quickly on
> the relevant branches.
Well, to be clear, it would be great if we could land some
improvements for v1.1 (which is based off version 18), but we're
locki
> There are a few things we're working on in SpiderMonkey that should improve
> this situation quite a bit:
Thanks, but I again need to emphasize that these are large, long-term
plans. Terrence tells me that GGC is planned for "sometime this
year". Lazy bytecode generation has been on the roadma
ere's a limit to how much we ought to expect from
the JS folks, particularly given how many other high-priority projects
you have.
On Mon, Apr 22, 2013 at 1:36 PM, Terrence Cole wrote:
> On 04/21/2013 04:51 PM, Justin Lebar wrote:
>> I think we should consider using much less JS in the
ch. But I suppose that's better than doing nothing, and if
we all can agree on doing that much, I'd be happy.
On Mon, Apr 22, 2013 at 10:40 AM, Boris Zbarsky wrote:
> On 4/21/13 7:51 PM, Justin Lebar wrote:
>>
>> Since most of these features implemented in JS seem to be
mphasize again that reducing the unused-arenas does not solve
all of our problems, only the single largest.
On Mon, Apr 22, 2013 at 11:05 AM, Mike Hommey wrote:
> On Mon, Apr 22, 2013 at 10:53:40AM -0400, Justin Lebar wrote:
>> > How about pre-compiling JS in JITed form?
>>
&
MB (00.16%) ── script-data
> ├──0.06 MB (00.13%) ── analysis-temporary
> ├──0.02 MB (00.04%) ── shapes-extra/tree-tables
> ├──0.02 MB (00.04%) ── other-sundries
> └──0.02 MB (00.03%) ── cross-compartment-wrappers
To me, this seems like death by a thousand cuts; there are /lots/ of
little
running code before we give
> up on it.
>
> Andreas
>
> Sent from Mobile.
>
> On Apr 22, 2013, at 7:05, Justin Lebar wrote:
>
>> Of course attachments don't work great on newsgroups. I've uploaded
>> the about:memory dumps I tried to attach to pe
Of course attachments don't work great on newsgroups. I've uploaded
the about:memory dumps I tried to attach to people.m.o:
http://people.mozilla.org/~jlebar/downloads/merged.json.xz
http://people.mozilla.org/~jlebar/downloads/unmerged.json.xz
On Sun, Apr 21, 2013 at 7:51 PM, Ju
I think we should consider using much less JS in the parts of Gecko that are
used in B2G. I'd like us to consider writing new modules in C++ where
possible, and I'd like us to consider rewriting existing modules in C++.
I'm only proposing a change for modules which are enabled for B2G. For modul
isappear at any time. This analogy works well for my developer workflow
> - I never put anything not derived from the build system in my object
> directory. But, I don't know what other people are doing. Could the
> anti-auto-clobberers please explain where this analogy falls apart
I think the possibility of deleting user data should be taken
seriously. Exactly who is doing the deletion (configure vs. make) is
immaterial. It's also not right to argue that since a majority of
users don't expect to lose data, it's OK to silently delete data for a
minority of them.
I think we
> It bothers me that we're cluttering up our commit messages with
> ephemeral data unrelated to the actual change. DONTBUILD and CLOSED
> TREE are the worst offenders.
What if we asked people to put DONTBUILD / CLOSED TREE in a new line
at the bottom of their commit message? Most of the time we l
Right now the status and tracking flags for a version get hidden when
that version becomes old. If we switched away from using
target-milestone, we'd need to prevent this from happening.
On Wed, Apr 10, 2013 at 4:53 PM, Alex Keybl wrote:
>> * The need for a particular team to track the concept o
> I see, so the hypothesis is that 100% of the fragmentation is coming from
> VirtualAlloc/MapViewOfFile, not from allocations in general?
jemalloc does not make 4kb allocations, I think ever. So yes.
On Tue, Apr 9, 2013 at 9:23 AM, Kevin Gadd wrote:
> I see, so the hypothesis is that 100% of t
> AIUI, on Windows the smallest block you can ask for with VirtualAlloc
> is 4 KiB. However, no more than one VirtualAlloc block can exist per
> 64 KiB chunk. So if you ask for 4 KiB you'll end up wasting the
> remaining 60 KiB of address space in the 64 KiB chunk.
Awesome memory, Nick.
MSDN se
> But can we do this with rebased changesets instead of "trivial" merge
> changesets?
Personally, I think merges are a Very Good idea because they bake into
the tree information that is currently contained only in the pushlog.
This improves bisect from my perspective, although I'll grant it might
If anything this should improve the experience of bisecting, because
you'll be able to bisect known-good csets on m-c and only at the end
step in to the merge csets which may or may not be good.
Right now we say that when people push a patch queue to m-c every
patch should be green, but in practic
This is a really interesting idea.
git is smart enough to let you pull only the csets that end up getting
merged into master. I don't know how multiple heads works with hg,
but I wonder if we could make hg smart enough to do the same thing.
Otherwise, maybe it's time to switch to git.
On Wed,
yntax builder page.
> http://trychooser.pub.build.mozilla.org/
>
> On 3 Apr, 2013, at 11:47 PM, Justin Lebar wrote:
>
> In general you'll have much more success running these benchmarks on
> tryserver rather than trying to run them locally. Even if you got the
> test working, there's no gu
In general you'll have much more success running these benchmarks on
tryserver rather than trying to run them locally. Even if you got the
test working, there's no guarantee that your local benchmark results
will have any bearing on the benchmark results on our servers. (In
particular, the server
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
This is awesome, Steve.
> Adding either a link to that, or examples directly, to
> http://trychooser.pub.build.mozilla.org/ would be awesome...
https://bugzilla.mozilla.org/show_bug.cgi?id=855591
On Wed, Mar 27, 2013 at 9:23 PM, Boris Zbarsky wrote:
> On 3/27/13 8:08 PM, Steve Fink wrote:
>>
>>
> hg-git (the tool we use to synchronize Mercurial and Git repos) supports
> subrepos. Although, I'm not sure how well it works.
Well, we should definitely figure this out before we move forward with
this plan.
If the hg support for git repos is decent, that might be a better way
to go, since the
> Since we believe if we go through with this it would be the first time we use
> a true subrepository system for a component
> used in mozilla-central, we'd very much appreciate any thoughts or feedback
> people might have on the idea.
Have you thought about how this hg subrepo will interact wi
> 4) Runs on every push
I thought many tests don't run on every push to m-i, due to
coalescing. (Just to be clear, I wish we could disable coalescing on
m-i!)
But also, PGO builds/tests are not run on every push to m-c.
-Justin
On Tue, Mar 26, 2013 at 10:10 AM, Ed Morley wrote:
> (Please repl
> 1) Preferences and all.js. We currently define most of the default
> preferences in /modules/libpref/src/init/all.js. There are things in there
> related to the browser, Necko, gfx, dom, etc. Prety much the kitchen sink.
> 2) Telemetry histograms. They are all defined in
> /toolkit/components/te
> 1) something checked into mc anyone can easily author or run (for tracking
> down regressions) without having to checkout a separate repo, or setup and
> run a custom perf test framework.
I don't oppose the gist of what you're suggesting here, but please
keep in mind that small perf changes ar
It sounds to me like people want both
1) Easier access to aggregated data so they can build their own
dashboards roughly comparable in features to the current dashboards.
2) Easier access to raw databases so that people can build up more
complex analyses, either by exporting the raw data from the
will detect these busted csets.
Follow along at home at
https://bugzilla.mozilla.org/show_bug.cgi?id=843081
-Justin
On Thu, Feb 21, 2013 at 6:36 AM, Gervase Markham wrote:
> On 20/02/13 16:06, Justin Lebar wrote:
>> The client bug that's fixed with the new version of hg is slowly and
> Don't we need to update our servers first due to phases? But either way,
> yes, this should be a bigger priority.
The client bug that's fixed with the new version of hg is slowly and
irreversibly ruining our blame, so I don't think we should wait before
upgrading clients.
Based on experience, b
upon what other
processes on the system are doing, and I'm not convinced that's a safe
thing to do in general.
But this is a better discussion to have in the context of DDD than in
the context of this bug.
-Justin
On Wed, Feb 13, 2013 at 9:13 AM, Benjamin Smedberg
wrote:
> On 2/1
Now that I've looked more closely, I take back my earlier "What Ed
said." The issue is more nuanced than I originally thought.
> To save everyone having to look at the graph - the initial landing showed a
> consistent 20% regression in trace malloc maxheap. If this were a 1-5%
> regression, then
> To save everyone having to look at the graph - the initial landing showed a
> consistent 20% regression in trace malloc maxheap. If this were a 1-5%
> regression, then I think it would be worth discussing the trade-off. At 20%,
> I really don't see how we can take this, sorry! :-(
I hope it's no
We've had bug 764220 open on the CPG memory regression for six months
now. Although it's a MemShrink:P1, it hasn't gotten the attention it
deserves.
FWIW, I think part of this stems from the fact that the MemShrink team
is often ineffective at getting others to fix bugs that we think are a
priori
e does not affect the
seriousness of the issue on that tree.
-Justin
On Fri, Jan 18, 2013 at 11:17 AM, Ehsan Akhgari wrote:
> On 2013-01-18 11:03 AM, Justin Lebar wrote:
>>
>> Fri, Jan 18, 2013 at 10:35 AM, Ehsan Akhgari
>> wrote:
>>>
>>> On Fri, Jan 1
Fri, Jan 18, 2013 at 10:35 AM, Ehsan Akhgari wrote:
> On Fri, Jan 18, 2013 at 5:39 AM, L. David Baron wrote:
>
>> So given that this is a regression in Firefox 19 (which is now on
>> beta), and the only reason we're not seeing this permaorange on beta
>> is because we don't generate non-debug ni
Due to bug 821502 [1], if you build Firefox 18 for Linux/Android with
GCC 4.4 (and perhaps earlier), GCC will miscompile the JS engine.
These miscompilations are known to cause test failures [2] and crashes
[3].
If you don't build on Linux/Android, don't care about building Firefox
18 (the current
Aren't anonymous mmap'ed pages automatically zeroed for you? (It has
to be this way for security reasons.) So I'd guess you could just
make an anonymous mmap (or the Windows equivalent) and you'd get what
you want.
Of course, I imagine your goal is not to pull in pages in RAM for
these zero page
> Are there any common installations of vi/vim that actually honor
> modelines anymore? The ones on the Linux distros that I used
> stopped doing so as a security measure.
:help modeline says
> No other commands than "set" are supported, for security reasons (somebody
> might create a Trojan hor
1 - 100 of 161 matches
Mail list logo
