Re: Some data on mozilla-inbound

On 4/22/13 9:54 PM, Kartikaya Gupta wrote: TL;DR: * Inbound is closed 25% of the time * Turning off coalescing could increase resource usage by up to 60% (but probably less than this). * We spend 24% of our machine resources on changes that are later backed out, or changes that are doing the back

Re: Some data on mozilla-inbound

Kartikaya Gupta wrote: The vast majority of changesets that are backed out from inbound are detectable on a try push Hopefully a push never burns all platforms because the developer tried it locally first, but stranger things have happened! But what I'm most interested in is whether patches

Re: Some data on mozilla-inbound

On 23/4/13 09:58, Neil wrote: Kartikaya Gupta wrote: The vast majority of changesets that are backed out from inbound are detectable on a try push Hopefully a push never burns all platforms because the developer tried it locally first, but stranger things have happened! But what I'm most inte

Re: Some data on mozilla-inbound

On 23 April 2013 09:58:41, Neil wrote: Hopefully a push never burns all platforms because the developer tried it locally first, but stranger things have happened! This actually happens quite often. On occasion it's due to warnings as errors (switched off by default on local machines due to too

Re: JavaScript reference changes: looking for opinions

Eric Shepherd wrote: Currently, the JavaScript reference content for the global classes (String, Array, etc), are divided up such that the class methods and properties and the prototype methods and properties are documented separately Function doesn't appear to be divided, while Object appea

Fw: JavaScript reference changes: looking for opinions

I've noticed our MDN pages climbing in search results over the last year or so, which is great to see. If we do fold pages like these together we should be carful to keep the pages that rank higher in search results. http://www.bing.com/search?form=MOZPSB&pc=MOZO&q=javascript+string+object htt

Re: Accelerating exact rooting work

At the moment it's really just Jono working full time on this, and terrence and other people reviewing. This stuff is actually quite easy and you can expect really fast review times from our side. In some parts of the code rooting could literally just mean to replace JS::Value to JS::RootedValue a

Re: Accelerating exact rooting work

On 04/23/2013 04:07 PM, Tom Schuster wrote: At the moment it's really just Jono working full time on this, and terrence and other people reviewing. This stuff is actually quite easy and you can expect really fast review times from our side. In some parts of the code rooting could literally just

Re: Accelerating exact rooting work

You wont have to bother with HandleObject or RootedObject etc. These are internal to js/ and we take care of these cases. Just use JS::Handle or JS::Rooted. Thanks for pointing people to this file. PS: The correct handle for Jon Coppeard is of course jonco! On Tue, Apr 23, 2013 at 3:58 PM, smaug

Re: Accelerating exact rooting work

There's a rooting guide on the wiki here: https://developer.mozilla.org/en-US/docs/SpiderMonkey/GC_Rooting_Guide It's not very thorough, but it's something. On Tue, Apr 23, 2013 at 3:14 PM, Tom Schuster wrote: > You wont have to bother with HandleObject or RootedObject etc. These > are interna

Re: Accelerating exact rooting work

Related nitpick: > *Warning:* The information at SpiderMonkey Garbage Collection > Tipsand > in the JSAPI User Guideis woefully out of date and

Re: Accelerating exact rooting work

On 2013-04-23 9:07 AM, Tom Schuster wrote: At the moment it's really just Jono working full time on this, and terrence and other people reviewing. This stuff is actually quite easy and you can expect really fast review times from our side. In some parts of the code rooting could literally just m

Re: Accelerating exact rooting work

Hmm, another question. Your list includes a bunch of stuff under tools/profiler, and I took a quick look and picked JSObjectBuilder.cpp. Changing the JS::Value's there to JS::RootedValue's cause compiler errors about conversion from jsvals when using macros such as INT_TO_JSVAL, STRING_TO_JSV

Re: Some data on mozilla-inbound

On 23/04/13 10:17, Ed Morley wrote: > Given that local machine time scales linearly with the rate at which we > hire devs (unlike our automation capacity), I think we need to work out > why (some) people aren't doing things like compiling locally and running > their team's directory of tests before

Re: Some data on mozilla-inbound

On 16:34, Tue, 23 Apr, Gervase Markham wrote: On 23/04/13 10:17, Ed Morley wrote: Given that local machine time scales linearly with the rate at which we hire devs (unlike our automation capacity), I think we need to work out why (some) people aren't doing things like compiling locally and runni

Re: Accelerating exact rooting work

On Tue, Apr 23, 2013 at 8:18 AM, Ehsan Akhgari wrote: > Can the stuff in objdir/dom/bindings be fixed whole-sale by changing the > WebIDL codegen? > Yes. bz is looking into it. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https:

Re: Some data on mozilla-inbound

>> The ratio of things landed on inbound which turn out to busted is really >> worrying On the one hand, we're told not to push to try too much, because that wastes resources. On the other hand, we're told not to burn m-i, because that wastes resources. Should we be surprised when people don't g

Re: Accelerating exact rooting work

On 04/23/2013 06:23 PM, Ehsan Akhgari wrote: Hmm, another question. Your list includes a bunch of stuff under tools/profiler, and I took a quick look and picked JSObjectBuilder.cpp. Changing the JS::Value's there to JS::RootedValue's cause compiler errors about conversion from jsvals when us

Re: Accelerating exact rooting work

On 4/23/13 11:18 AM, Ehsan Akhgari wrote: Does this also apply to code holding on to JSObject*s? If you're holding them on the heap... sigh. Just trace them and use fromMarkedLocation as needed; there is nothing better at the moment. You can't use JS::Rooted on the heap. Can the stuff in

Re: Some data on mozilla-inbound

On 13-04-23 11:41 , Chris AtLee wrote: We've considered enforcing this using some cryptographic token. After you push to try and get good results, the system gives you a token you need to include in your commit to m-i. ... or you could just merge the cset directly from try to m-i or m-c. (i.e.

Re: Some data on mozilla-inbound

On 13-04-23 00:39 , Ehsan Akhgari wrote: How hard would it be to gather a list of the total number of patches being backed out plus the amount of time that we spent building/testing those, hopefully in a style similar to ? Not trivia

Re: Some data on mozilla-inbound

On 13-04-23 03:57 , Axel Hecht wrote: Do we know how many of these have been pushed to try, and passed/compiled what they'd fail later? I haven't looked at this. It would be useful to know but short of pulling patches and using some similarity heuristic or manually examining patches I can't t

Re: Some data on mozilla-inbound

On Tue, Apr 23, 2013 at 8:41 AM, Chris AtLee wrote: > We've considered enforcing this using some cryptographic token. After you > push to try and get good results, the system gives you a token you need to > include in your commit to m-i. Sounds like the goal of this kind of solution would be to e

Re: Automatic tree clobbering is coming

On 4/17/2013 6:12 PM, Gregory Szorc wrote: I agree that we should consider a compromise regarding the UI/UX of auto clobber. I have filed bug 863091. I would like to say that I view the object directory as a cache of the output of the build system. Since it's a cache, cache rules apply and da

Re: Some data on mozilla-inbound

On Tue, Apr 23, 2013 at 9:28 AM, Kartikaya Gupta wrote: > Not trivial, but not too difficult either. Do we have any evidence to show > that the try highscores page has made an impact in reducing unnecessary try > usage? It's been used by people like Ed Morley to reach out to individual developers

Re: Accelerating exact rooting work

- Original Message - > Does this also apply to code holding on to JSObject*s? I've been > adding a whole bunch of those cases lately. If you are telling the cycle collector about those JSObjects, then it should get fixed whenever CCed stuff is fixed. Andrew _

Re: Some data on mozilla-inbound

On 04/23/13 02:17, Ed Morley wrote: > On 23 April 2013 09:58:41, Neil wrote: >> Hopefully a push never burns all platforms because the developer tried >> it locally first, but stranger things have happened! > > This actually happens quite often. On occasion it's due to warnings as > errors (switch

Re: Some data on mozilla-inbound

On 23/04/2013 17:28, Kartikaya Gupta wrote: On 13-04-23 00:39 , Ehsan Akhgari wrote: How hard would it be to gather a list of the total number of patches being backed out plus the amount of time that we spent building/testing those, hopefully in a style similar to

Re: Some data on mozilla-inbound

On 4/23/13 1:17 PM, David Keeler wrote: I would like to know a bit more about this. Is our list of supported toolchains so diverse that building with one version versus another will report so many false positives as to be useless? Yes. For example a typical clang+ccache build of the tree with

Re: Automatic tree clobbering is coming

On 18/04/2013 11:02, Ed Morley wrote: On 17/04/2013 20:51, Ms2ger wrote: On 04/17/2013 09:36 PM, Gregory Szorc wrote: It /could/, sure. However, I consider auto clobbering a core build system feature (sheriffs were very vocal about wanting it). As such, it needs to be part of client.mk. (Please

Re: Some data on mozilla-inbound

On 4/23/13 6:35 PM, Kartikaya Gupta wrote: On 13-04-23 03:57 , Axel Hecht wrote: Do we know how many of these have been pushed to try, and passed/compiled what they'd fail later? I haven't looked at this. It would be useful to know but short of pulling patches and using some similarity heurist

Re: Rethinking the amount of system JS we use in Gecko on B2G

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

Re: Some data on mozilla-inbound

On 2013-04-23 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 "really worrying", what do you think our goal should be? Less than that? It's really hard to come up

Re: Some data on mozilla-inbound

On Mon, Apr 22, 2013 at 12:54 PM, Kartikaya Gupta wrote: > TL;DR: > * Inbound is closed 25% of the time > * Turning off coalescing could increase resource usage by up to 60% (but > probably less than this). > * We spend 24% of our machine resources on changes that are later backed > out, or change

Re: Some data on mozilla-inbound

On Wed, Apr 24, 2013 at 11:21 AM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > - The 'inbound was closed for 15.3068% of the total time due to > "bustage"' number is an underestimate, in one sense. When inbound is > closed at 10am California time, it's a lot more inconvenient to > devel

Re: Some data on mozilla-inbound

On 13-04-23 19:21 , Nicholas Nethercote wrote: - The 'inbound was closed for 15.3068% of the total time due to "bustage"' number is an underestimate, in one sense. When inbound is closed at 10am California time, it's a lot more inconvenient to developers than when it's busted at midnight Califor

Re: Rethinking the amount of system JS we use in Gecko on B2G

On Monday, April 22, 2013 7:28:30 AM UTC-7, Justin Lebar wrote: > > The issue isn't compilation of code; that doesn't stick out in the > memory reports. The issue seems to be mostly the overhead of the JS > engine for each file (even if the file stores very little data, as > BrowserElementParent