Re: IID Change Hook

2013-01-22 Thread Scott Johnson
> Note that we previously added a hook[1] to check that > binary-compat-breaking changes on Beta didn't land without explicit > approval. I suspect we could extend that hook to do what we want for > mozilla-central. True, but this hook actually (IIUC) checks to see if an IID changed, given a patc

B2G UA override criteria

2013-01-22 Thread Lawrence Mandel
(cross posting to dev-platform, dev-b2g, and compatibility - please respond to dev-platform) As a mitigation strategy for sites serving non mobile content to B2G, we added a UA override (domain whitelist) mechanism that allows B2G to send a custom UA to a specific domain. For example, B2G sends

Re: Effects of JSM Compartments on Performance and Development Practices

2013-01-22 Thread Nicholas Nethercote
On Tue, Jan 22, 2013 at 2:15 PM, Boris Zbarsky wrote: > On 1/20/13 2:37 PM, Gregory Szorc wrote: >> >> * Have all or most of chrome-privileged JS share the same compartment >> (like on B2G). It's my understanding the CPG decision was largely driven >> by content/security requirements and chrome ju

Re: IID Change Hook

2013-01-22 Thread Ted Mielczarek
On 1/22/2013 5:51 PM, Scott Johnson wrote: > Hello Dev-Platform: > > tl;dr: > As discussed in the platform meeting today, we're looking at adding a > checking script to verify that IIDs are changed along with interfaces > from now on. The relevant bug is > https://bugzilla.mozilla.org/show_bug.cgi?

IID Change Hook

2013-01-22 Thread Scott Johnson
Hello Dev-Platform: tl;dr: As discussed in the platform meeting today, we're looking at adding a checking script to verify that IIDs are changed along with interfaces from now on. The relevant bug is https://bugzilla.mozilla.org/show_bug.cgi?id=477166 Full Text: In light of recent breakages of p

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Mike Hommey
On Tue, Jan 22, 2013 at 05:09:10PM -0500, Ehsan Akhgari wrote: > On 2013-01-22 4:40 PM, Robert O'Callahan wrote: > >On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari >> wrote: > > > >But note that unless a given code path is examined throughout the > >profiling

Re: Effects of JSM Compartments on Performance and Development Practices

2013-01-22 Thread Boris Zbarsky
On 1/20/13 2:37 PM, Gregory Szorc wrote: * Have all or most of chrome-privileged JS share the same compartment (like on B2G). It's my understanding the CPG decision was largely driven by content/security requirements and chrome just got caught up in it. What's not clear to me is whether this is

Re: Effects of JSM Compartments on Performance and Development Practices

2013-01-22 Thread Boris Zbarsky
On 1/20/13 4:01 PM, Joshua Cranmer wrote: If it were possible to have strings cross-compartments that don't require flattening and excessive copying, that would make the lives of add-on authors in a CPG world much easier. Please make sure bugs are filed? -Boris ___

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Ehsan Akhgari
On 2013-01-22 4:40 PM, Robert O'Callahan wrote: On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: But note that unless a given code path is examined throughout the profiling phase of a PGO build, PGO will probably have negligible effect on it, if

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Robert O'Callahan
On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari wrote: > But note that unless a given code path is examined throughout the > profiling phase of a PGO build, PGO will probably have negligible effect on > it, if any. The PGO compiler looks for hot code paths and tries to > optimize those, so for exa

Re: MemShrink meeting 01/22/2013 @ 2:00pm PST

2013-01-22 Thread Jet Villegas
Late Meeting Room Change! Please use "TOR-5N Spadina" for today's MemShrink meeting. >> This week's MemShrink meeting will be brought to you by this awesome bug fix: https://bugzilla.mozilla.org/show_bug.cgi?id=795988 Note: * New meeting/vidyo room (this week only) The wiki page for this meet

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Ehsan Akhgari
OK, everyone. Both mozilla-central and mozilla-inbound are *temporarily* reopened now. Please be gentle. Cheers, -- Ehsan On Tue, Jan 22, 2013 at 9:06 AM, Ehsan Akhgari wrote: > Status update #3: > > It seems like with PGO disabled for all of the above modules, we'

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Ehsan Akhgari
On 2013-01-22 9:45 AM, Marco Bonardo wrote: On 22/01/2013 15:36, Benjamin Smedberg wrote: On 1/22/2013 9:28 AM, Axel Hecht wrote: How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I would not exp

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Marco Bonardo
On 22/01/2013 15:36, Benjamin Smedberg wrote: On 1/22/2013 9:28 AM, Axel Hecht wrote: How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I would not expect PGO to optimize any of the RDF code for s

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Benjamin Smedberg
On 1/22/2013 9:28 AM, Axel Hecht wrote: How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I would not expect PGO to optimize any of the RDF code for speed, even if they were in the startup codepat

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Axel Hecht
How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I'm not overly concerned, but wanted to make sure we look. Axel On 22.01.13 15:06, Ehsan Akhgari wrote: Status update #3: It seems like with P

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Ehsan Akhgari
On Tue, Jan 22, 2013 at 7:35 AM, Mike Hommey wrote: > On Tue, Jan 22, 2013 at 01:30:50PM +0100, Mike Hommey wrote: > > On Mon, Jan 21, 2013 at 11:32:34PM -0500, Ehsan Akhgari wrote: > > > Second status update: > > > > > > The numbers from disabling PGO on image, accessible and webrtc are in, > an

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Ehsan Akhgari
Status update #3: It seems like with PGO disabled for all of the above modules, we've now decreased the linker max vmem size by about 500MB, which is nice. There is one PGO build bustage < https://tbpl.mozilla.org/php/getParsedLog.php?id=19006659&tree=Mozilla-Inbound> which has been re-triggered,

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Mike Hommey
On Tue, Jan 22, 2013 at 01:30:50PM +0100, Mike Hommey wrote: > On Mon, Jan 21, 2013 at 11:32:34PM -0500, Ehsan Akhgari wrote: > > Second status update: > > > > The numbers from disabling PGO on image, accessible and webrtc are in, and > > the linker max vmem size is down by only ~200MB, which is q

Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit

2013-01-22 Thread Mike Hommey
On Mon, Jan 21, 2013 at 11:32:34PM -0500, Ehsan Akhgari wrote: > Second status update: > > The numbers from disabling PGO on image, accessible and webrtc are in, and > the linker max vmem size is down by only ~200MB, which is quite > disappointing, especially since according to Randell, putting we