Re: Website memory leaks

[Nick Fitzgerald]

On Mon, Nov 6, 2017 at 1:53 AM, David Teller  wrote:

> I wanted to add something like that to about:performance, but at the
> time, my impression was that we did not have sufficient platform data on
> where allocations come from to provide something convincing.
>

​The SpiderMonkey Debugger API has hooks to capture the JS stack with some
probability for each JS object allocation:
https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#Allocation_Site_Tracking

The probability allows you to dial up or down the overhead vs amount of
data trade off.

The API was designed in such a way that it doesn't disable ion compilation
when enabled. It's not somethign we' want on all the time for everyone, but
should have low enough overhead that we could turn it on in something like
about:performance.

Would be great to expand that API to observe JS string allocations as
well.​​ C++ allocations could be useful too, but there are a lot more open
questions there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Website memory leaks

[Nick Fitzgerald]

We have https://bugzilla.mozilla.org/show_bug.cgi?id=1243091 on file for
automatic leak detection in the DevTools' memory panel.

I'd have liked to try implementing
http://www.cs.utexas.edu/ftp/techreports/tr06-07.pdf because it can see
through frameworks/libraries (or claims to in a convincing way, at least)
and point to the "user" code that is transitively responsible. In today's
modern web that is full of every kind of framework and library, that seems
like a very useful property to have.

As far as seeing the CC's heap, there is
https://bugzilla.mozilla.org/show_bug.cgi?id=1057057 on file for that. It
shouldn't be hard for someone who understand the CC and all of its macros.
You basically just make a specialization of JS::ubi::Concrete that can
enumerate outgoing edges and report shallow size.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Nick Fitzgerald]

Does `mach try` still require `git cinnabar` when using a `git` checkout of
m-c, or does it work with `moz-git-tools` now too?

Thanks,

Nick

On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc  wrote:

> The Try Service ("Try") is a mechanism that allows developers to schedule
> tasks in automation. The main API for that service is "Try Syntax" (e.g.
> "try: -b o -p linux -u xpcshell"). And the transport channel for making
> that API call is a Mercurial changeset's commit message plus a version
> control "push" to the "try" repository on hg.mozilla.org.
>
> As the recent "Reminder on Try usage and infrastructure resources" thread
> details, scaling Firefox automation - and Try in particular - is
> challenging. In addition, the number of workflows and variations that
> automation needs to support is ever increasing and continuously evolving.
>
> It shouldn't come as a surprise when I say that we've outgrown many of the
> implementation details of the Try Service. Try Syntax itself is over 7
> years old and has survived a complete rewrite of automation scheduling, for
> example. Aspects of Try are adversely impacting the ability for developers
> to use Try efficiently and therefore undermining our collective ability to
> get important work done quickly.
>
> In order to put ourselves in a position to more easily change
> implementation details of the Try Service so we may deliver a better
> experience for all, we'd like to require the use of `mach try` for Try
> submissions. This will ensure there is a single, well-defined, and
> easily-controlled mechanism for submitting to Try. This will allow greater
> flexibility and adaptability. It will provide better opportunities for user
> messaging. It will ensure that any new features are seen by everyone
> sooner. It will eventually lead to faster results on Try for everyone.
>
> Bug 1400330 ("require-mach-try") is on file to track requiring `mach try`
> to submit to Try.
>
> The mechanism for submitting to Try has remaining relatively stable for
> years. `mach try` is relatively new - and I suspect unused by a sizeable
> population. This is a potentially highly disruptive transition. That's why
> we're not making it immediately and why we're sending this email today.
>
> You can mitigate the disruption by using `mach try` before the forced
> transition is made and reporting bugs as necessary. Have them block
> "require-mach-try" if you need them addressed before the transition or
> "mach-try" otherwise. We don't really have a good component for `mach try`
> bugs, so put them in TaskCluster :: Task Configuration for now and chain
> them to a tracking bug for visibility.
>
> FAQ
>
> Q: When will the transition be made?
> A: When we feel `mach try` is usable for important workflows (as judged by
> blockers on "require-mach-try"). Also, probably not before Firefox 57 ships
> because we don't want to interfere with that release.
>
> Q: What about old changesets?
> A: You will still be able to submit to Try using the current/legacy
> mechanism for old changesets. There will be a "flag day" of sorts on
> mozilla-central after which all Try submissions will require `mach try` or
> nothing will get scheduled.
>
> Q: Will Try Syntax continue to work?
> A: For the foreseeable future, yes. There is a long-term goal to replace
> Try Syntax with something more automatic and less effort - at least for
> most use cases. But there are no definite plans or a timetable to remove
> Try Syntax.
>
> Q: Are there any other major changes planned?
> A: Several. People are hacking on path-based selection, `mach try fuzzy`
> improvements, moz.build-based annotations influencing what gets scheduled,
> not using a traditional Mercurial repository for backing Try, and more.
> Some of these may not be available to legacy Try submission workflows,
> giving you additional reasons to adopt `mach try` sooner.
>
> Q: Should I be worried about this transition negatively impacting my
> workflow?
> A: As long as you file bugs blocking "require-mach-try" to make it known
> why `mach try` doesn't work for you, your voice will be heard and hopefully
> acted on. So as long as you file bugs, you shouldn't need to worry.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Rust bindings to SpiderMonkey on inbound

[Nick Fitzgerald]

(cc dev-servo, dev-platfrom; reply to js-engine-internals)

Hello everyone!

The Rust bindings to SpiderMonkey that Servo uses just landed in
mozilla-inbound[0]! You can monitor their test results on taskcluster as
the `SM-tc[tier-2](rust)` job.

If any of your patches break these tests, please ping me or Till
Schneidereit and we can get them passing again together.

This marks the beginning of the end of Servo forking SpiderMonkey and
applying custom patches to work around old bindgen bugs. That forking has
been making updating to new SpiderMonkey releases a terrible pain for
Servo. No more!

Thanks to everyone involved in getting this patch series landed!

Nick

[0]
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound=a8ae266cd61eb004d4f74a989e4d9c6d2ceb5b93
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Nick Fitzgerald]

On Wed, May 17, 2017 at 10:51 AM, Tom Tromey  wrote:

> > "Boris" == Boris Zbarsky  writes:
>
> >> https://github.com/source-map/source-map-rfc
>
> Boris> Are there any plans to have a standard here?
>
> All I found was this:
> https://groups.google.com/forum/#!topic/mozilla.dev.js-
> sourcemap/SD8sZ_7VFpw
>
> ... my reading of that was that there wasn't interest on our part at the
> time.  I suppose we could reopen that.
>

​At the time of the thread, I had hopes that the source map RFC repo would
take off. It never did. Maybe making a "proper"​ WHATWG standard would help
get people involved, in which case it would be a good idea. I wasn't trying
to push back in that thread, just making sure that we had good answers to
those questions because if we didn't then why do it in the first place.

In my experience, trying to get anyone to comment or provide feedback on
source map RFCs was a huge pain, and it felt to me like nobody (other
browser devtools teams, maintainers of compilers targeting JS) cared enough
about source maps to get involved or contribute.

If the effort re-materializes, here's what I think should be focused on:

* Clean up the spec text and any ambiguities it may have; make it a
"proper" standard
* Pull a wasm on the source map format: create an isomorphic, but much more
compact binary format
* Add the ability to encode source level scopes, bindings, and a way to
recover bindings' values
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Nick Fitzgerald]

Error().stack is not affected by source maps (nor should it be IMO). This
is just devtools facing with nothing that is web observable.

On Wed, May 17, 2017 at 9:06 AM, Boris Zbarsky  wrote:

> On 5/17/17 11:01 AM, Tom Tromey wrote:
>
>> In this case I think this does not apply, because as far as I'm aware
>> source maps are not part of any standard process; rather there is:
>>
>> https://github.com/source-map/source-map-rfc
>>
>
> Are there any plans to have a standard here?  It really would be good to
> have all UAs converge on a single format here, both for the header and for
> the sourcemap itself, especially if we're going to have an unprefixed name
> for the header...  Speaking of which, is there a plan to register this
> header with IANA (see )?
>
> Is there any web-page-observable behavior change from sourcemaps (e.g.
> .stack on exceptions?), or is it all about how devtools behave?
>
> -Boris
>
> ___
> 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

Re: FYI: We've forked the Breakpad client code

[Nick Fitzgerald]

I can review the DWARF related bits in a pinch, too.

On Thu, Feb 9, 2017 at 2:04 PM, Mike Hommey  wrote:

> On Thu, Feb 09, 2017 at 12:41:07PM -0800, Jim Blandy wrote:
> > Under the circumstances, I'll volunteer to review, if that's feasible.
>
> I can too.
>
> > On Thu, Feb 9, 2017 at 12:37 PM, Ted Mielczarek 
> wrote:
> >
> > > On Thu, Feb 9, 2017, at 02:47 PM, Aaron Klotz wrote:
> > > > This is great news, Ted!
> > > >
> > > > Are you going to be creating a module for this? Who are the peers?
> > >
> > > I don't think a new module is necessary, we've covered the existing
> > > integration code (nsExceptionHandler.cpp etc) under the Toolkit module
> > > for a long time and I think it's been OK. If it becomes a problem we
> can
> > > certainly reevaluate. There aren't a lot of people that are comfortable
> > > reviewing this code, but that's not exactly a unique situation in
> Gecko.
> > >
> > > -Ted
> > > ___
> > > 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
> ___
> 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

Re: Introducing mozilla::Result for better error handling

[Nick Fitzgerald]

FWIW, you can also avoid the
check-for-error-and-early-return-or-else-unwrap dance that is being
"hidden" within MOZ_TRY by using `mozilla::Result::andThen` (and
`mozilla::Result::map`) which are on inbound and will be on m-c soon.

The patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1324829 has
example usage.

On Thu, Dec 22, 2016 at 10:20 AM, Kris Maglione 
wrote:

> On Wed, Dec 21, 2016 at 11:22:24PM -0800, Eric Rahm wrote:
>
>> The key point for me is that we're hiding the return. I'm fine with the
>> more verbose explicitly-return-and-make-it-easier-for-the-reviewer-to-cal
>> l-out-issues
>> form.
>>
>
> I've never been convinced by that argument. Reviewers accept code with
> early return macros should be familiar enough with them that they don't
> make it any harder to spot issues caused by early return. On the flip side,
> explicit early return is a pervasive enough pattern that I think most of us
> tend to just filter it out as noise. But it's noise that makes the
> structure of the code much harder to follow, which makes other errors much
> easier to miss.
>
> And, by the same token, this is part of MFBT, and comes along with a lot
> of other helpers, and a general coding style, that makes it much easier to
> RAII all the things, and to generally do the right thing. In isolation, I
> might worry more about it leading to new early return errors, but in
> context, I think it's clearly a step in the right direction.
>
>
> On Wed, Dec 21, 2016 at 10:59 PM, Kris Maglione 
>> wrote:
>>
>> On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric Rahm wrote:
>>>
>>> I like the idea of pulling in some Rusty concepts, but I'm concerned
 about
 adding yet another early return macro -- absolutely no arguments on the
 new
 type, just the |MOZ_TRY| macro. In practice these have lead to security
 issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you
 NS_ENSURE). These aren't hypothetical issues, I've run into them both
 working on memshrink and sec issues in Firefox.


>>> We run into the same issues without those macros. The only real
>>> difference
>>> is that when you have to follow every call with:
>>>
>>>  if (NS_WARN_IF(NS_FAILED(rv))) {
>>>return rv;
>>>  }
>>>
>>> It's much easier to lose track of the allocation you did four  calls ago
>>> that's now 20 lines away.
>>>
>>>
>>> On Wed, Dec 21, 2016 at 9:53 AM, Ted Mielczarek 
>>>
 wrote:

 On Wed, Dec 21, 2016, at 12:30 PM, Jason Orendorff wrote:

> > The implicit conversion solves a real problem. Imagine these two
> > operations
> > have two different error types:
> >
> > MOZ_TRY(JS_DoFirstThing()); // JS::Error&
> > MOZ_TRY(mozilla::pkix::DoSecondThing()); // pkix::Error
> >
> > We don't want our error-handling scheme getting in the way of using
> them
> > together. So we need a way of unifying the two error types: a shared
> base
> > class, perhaps, or a variant.
> >
> > Experience with Rust says that MOZ_TRY definitely needs to address
> this
> > problem somehow. C++ implicit conversion is just one way to go; we
> can
> > discuss alternatives in the bug.
>
> The `try` macro in Rust will auto-convert error types that implement
> `Into`, AIUI, but that's not automatic for all error types. I
> haven't
> tried it, but I have seen multiple recommendations for the
> `error_chain`
> crate to make this smoother:
> https://docs.rs/error-chain/0.7.1/error_chain/
>
> It's basically just boilerplate to implement conversions from other
> error types. I wouldn't be surprised if something like that percolates
> into the Rust standard library at some point.
>
> -Ted
> ___
> 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


>>> --
>>> Kris Maglione
>>> Firefox Add-ons Engineer
>>> Mozilla Corporation
>>>
>>> It's always good to take an orthogonal view of something.  It develops
>>> ideas.
>>> --Ken Thompson
>>>
>>>
>>>
> --
> Kris Maglione
> Firefox Add-ons Engineer
> Mozilla Corporation
>
> Life is too important to be taken seriously.
> --Oscar Wilde
>
>
> ___
> 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

Re: Introducing mozilla::Result for better error handling

[Nick Fitzgerald]

Thanks for getting this landed! Hooray for better error handling! \o/

On Tue, Dec 20, 2016 at 5:46 AM, Jan de Mooij  wrote:

> Hi all,
>
> A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked
> to inform dev-platform about this, so here's a quick overview.
> mozilla::Result is based on Rust's Result type [2]. It contains
> either a success value of type V or an error value of type E. For example,
> a function Foo that returns an `int` on success or some `Error` (enum,
> pointer, etc) on failure, would have this signature:
>
>   Result Foo();
>
> mozilla::Ok is an empty struct that can be used when a function doesn't
> return anything on success:
>
>   Result Bar() { ... return Ok(); }
>
> The MOZ_TRY(expr) macro is similar to Rust's try! macro: if `expr` is an
> error it propagates it to the caller, else it continues:
>
>   Result Baz() { MOZ_TRY(Bar()); ... }
>
> There's also a MOZ_TRY_VAR macro that can be used when you want to store
> the return value on success. Result has isOk(), isErr(), unwrapOk(),
> unwrapErr() methods that do what you'd expect. It also has the
> MOZ_MUST_USE_TYPE annotation, so the static analysis builds will complain
> if you ignore the return value of a function that returns Result.
>
> Internally, Result uses mozilla::Variant, but there are some cases that can
> be stored more efficiently. For instance, Result just stores an
> Error* pointer and Ok is represented as nullptr. This is more efficient and
> will also make it easier to call functions that return Result from JIT
> code. The documentation [3] has more info.
>
> The long-term plan is to use Result in SpiderMonkey, to simplify our
> error/OOM handling [4][5].
>
> Many thanks to Jason Orendorff (jorendorff) for doing most of the work by
> writing the initial Result patches, and to Jeff Walden (Waldo) for his
> thorough code reviews.
>
> Jan
>
> [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1283562
> [1] https://searchfox.org/mozilla-central/source/mfbt/Result.h
> [2] https://doc.rust-lang.org/std/result/
> [3]
> https://searchfox.org/mozilla-central/rev/cc2a84852bd4e6f6d8d4d5b17b8382
> bb5d005749/mfbt/Result.h#148-158
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1277368
> [5] https://searchfox.org/mozilla-central/source/js/public/Result.h
> ___
> 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

Re: So, what's the point of Cu.import, these days?

[Nick Fitzgerald]

On Wed, Sep 28, 2016 at 1:19 AM, David Teller  wrote:

>
> * CommonJS
>

​Just a heads up: the devtools have been using CommonJS modules and lazily
requiring modules for a couple years now. If you don't want to jump
directly to ES modules, reusing our infrastructure is probably a good idea.
We also run eslint on this stuff, but I don't know exactly how much
integration it has with our lazy requires.

http://searchfox.org/mozilla-central/search?q=lazyRequireGetter=false=false=
​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

[Nick Fitzgerald]

Thanks Kan-Ru! I've personally tried to include the header with the wrong
case multiple times, so I appreciate this change a lot.

On Fri, Aug 26, 2016 at 7:54 PM, Kan-Ru Chen  wrote:

> Hello,
>
> In Bug 1297276 I landed a patch to rename mozilla/unused.h to
> mozilla/Unused.h to make it more consistent with our other MFBT headers.
> Normally rename a header shouldn't cause too much trouble, however this
> rename is only changing the case so you might experience some problems
> on case insensitive filesystem.
>
> As pointed out by Tim in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1297276#c19 if you use
> |git pull -f| to update local copy of gecko and git refuse to, you can
> rm mfbt/unused.* first to make git happy.
>
> HPH
> Kanru
> ___
> 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

Re: New [must_use] property in XPIDL

[Nick Fitzgerald]

On Mon, Aug 22, 2016 at 4:39 PM, R Kent James  wrote:

> On 8/21/2016 9:14 PM, Nicholas Nethercote wrote:
> > I strongly encourage people to do likewise on
> > any IDL files with which they are familiar. Adding appropriate checks
> isn't
> > always easy
>
> Exactly, and I hope that you and others restrain your exuberance a
> little bit for this reason. A warning would be one thing, but a hard
> failure that forces developers to drop what they are doing and think
> hard about an appropriate check
>

​Developers absolutely must already be thinking hard about appropriate
checks when calling fallible functions.​ These kinds of annotations make
our lives easier, not harder, in the long run.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Nick Fitzgerald]

Ok, I've filed this bug to use @@toStringTag in the debugger instead of
Debugger.Object.prototype.class:
https://bugzilla.mozilla.org/show_bug.cgi?id=1278310

On Mon, Jun 6, 2016 at 10:35 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 6/6/16 12:23 PM, Nick Fitzgerald wrote:
>
>> Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
>> misunderstood the scope of this proposal, the class name exposed by that
>> getter should not change, only the `Object.prototype.toString.call(thing)`
>> would change.
>>
>
> You misunderstood the scope.  We would be changing the class string if we
> change the web-facing behavior here.
>
> Or put another way, if we want to change to @@toStringTag for DOM objects
> (which we do) and _if_ we want that change to change the behavior of
> Object.prototype.toString on DOM prototypes, then we would roll that out in
> two stages:
>
> 1)  Change the class strings on DOM prototype objects, so the
> Object.prototype.toString changes (and the Debugger.Object.prototype.class
> thing changes too, sadly).
>
> 2)  Add @@toStringTag stuff.
>
> The idea being to separate breakage from the Object.prototype.toString
> changing from breakage from using @@toStringTag instead of class strings to
> implement the behavior.
>
>
> -Boris
> ___
> 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

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Nick Fitzgerald]

Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
misunderstood the scope of this proposal, the class name exposed by that
getter should not change, only the `Object.prototype.toString.call(thing)`
would change.

On Mon, Jun 6, 2016 at 12:18 AM, Panos Astithas <p...@mozilla.com> wrote:

> On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald <nfitzger...@mozilla.com>
> wrote:
>
>> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
>>
>> > Devtools bug: none so far, but maybe we need one?  Does devtools rely on
>> > the JSClass name or Object.prototype.toString anywhere?
>> >
>>
>> ​I think we are fine. There are certainly places where we use the
>> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack, but
>> I don't see any instances that would be tripped up by these changes.
>>
>>
>> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
>>
>
> Don't we still use the JSClass name in the variables view to indicate the
> object type (reflected from Debugger.Object.prototype.class)?
>
> Panos
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Static analysis for "use-after-move"?

[Nick Fitzgerald]

We could create a MoveGuard, similar to ReentrancyGuard, that sets a `moved
= true` flag in debug builds and make methods assert against that.

(But it isn't nearly as nice as having borrowck...)

On Wed, Apr 27, 2016 at 5:53 PM, smaug  wrote:

> On 04/28/2016 08:00 AM, Gerald Squelart wrote:
>
> Because sometimes the function will choose not to actually move from an
>> rvalue-ref
>>
>
> FWIW, this is the reason why I think Move is broken by definition. Move
> doesn't move anything.
> It should have been designed differently, so that a temporary object is
> created to ensure move is always happening or something like that
> (though, that might lead to leaks in some cases).
>
>
>
> ___
> 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

Re: PSA: Dump GC's retaining paths for any GC thing while debugging with JS::ubi::dumpPaths

[Nick Fitzgerald]

Here is a change I made when investigating `ScriptSource`s outliving their
`JSRuntime` because of `ScriptSourceObject`s being considered reachable
after the final DESTROY_RUNTIME collection, and therefore not having their
finalizer run, which would have freed the leaking `ScriptSource`s. I am
iterating all cells in all zones to find `ScriptSourceObject`s and dump
their retaining paths.

@@ -366,16 +368,29 @@ JSRuntime::init(uint32_t maxbytes, uint32_t
maxNurseryBytes)
 JSRuntime::~JSRuntime()
 {
 MOZ_ASSERT(!isHeapBusy());
 MOZ_ASSERT(childRuntimeCount == 0);

 fx.destroyInstance();

 if (gcInitialized) {
+fprintf(stderr, "FITZGEN: Check for leaking ScriptSourceObject
*BEFORE* final GC on runtime\n");
+for (ZonesIter zone(this, WithAtoms); !zone.done(); zone.next()) {
+for (auto kind : ObjectAllocKinds()) {
+for (ZoneCellIter i(zone, kind); !i.done(); i.next()) {
+if (i.get()->is()) {
+fprintf(stderr, "FITZGEN: FOUND MAYBE LEAKING
ScriptSourceObject VIA CELL ITER!!!\n");
+JS::ubi::Node node(i.get());
+JS::ubi::dumpPaths(this, node);
+}
+}
+}
+}
+
 /* Free source hook early, as its destructor may want to delete
roots. */
 sourceHook = nullptr;

 /*
  * Cancel any pending, in progress or completed Ion compilations
and
  * parse tasks. Waiting for AsmJS and compression tasks is done
  * synchronously (on the main thread or during parse tasks), so no
  * explicit canceling is needed for these.


On Mon, Apr 25, 2016 at 10:26 AM, Jim Blandy <jbla...@mozilla.com> wrote:

> Could you show a sample patch that uses this?
>
> On Mon, Apr 25, 2016 at 10:19 AM, Nick Fitzgerald <nfitzger...@mozilla.com
> > wrote:
>
>> Hi everyone!
>>
>> Friendly PSA: sometimes you're debugging a "leak" where the GC considers
>> something reachable and therefore won't collect it, and this happens at an
>> inopportune time for using the devtools memory panel (eg right before a
>> DESTROY_RUNTIME collection), so you can't use the nice GUI for visualizing
>> the GC's retaining paths.
>>
>> Fear not! You can use `JS::ubi::dumpPaths` to log retaining paths of any
>> GC
>> thing from within GDB, or you can compile it in as you might do with a
>> tactically placed printf.
>>
>> The signature is `void JS::ubi::dumpPaths(JSRuntime* rt, JS::ubi::Node
>> node, maxRetainingPaths = 10)`. The `rt` should be the runtime that the
>> thing belongs to, `node` is the thing (JS::ubi::Node constructs from raw
>> GC
>> pointers as well as Rooted and Handle), and `maxRetainingPaths` is the
>> number of retaining paths to dump.
>>
>> Include the "js/UbiNodeShortestPaths.h" header to get
>> `JS::ubi::dumpPaths`.
>>
>> Happy bug hunting!
>>
>> Example output:
>>
>> Path 0:
>> 0x7fff5fbfec10 JS::ubi::RootList
>> |
>> |
>> ''
>> |
>> V
>> 0x115c49d80 JSObject
>> |
>> |
>> 'shape'
>> |
>> V
>> 0x12ac4db50 js::Shape
>> |
>> |
>> 'base'
>> |
>> V
>> 0x116244e70 js::BaseShape
>> |
>> |
>> 'ShapeTable shape'
>> |
>> V
>> 0x116289120 js::Shape
>> |
>> |
>> 'getter'
>> |
>> V
>> 0x11627b3a0 JSObject
>> |
>> |
>> 'private'
>> |
>> V
>> 0x11855d940 JSObject
>> |
>> |
>> 'script'
>> |
>> V
>> 0x113290bf0 JSScript
>> |
>> |
>> 'sourceObject'
>> |
>> V
>> 0x1132763c0 JSObject
>>
>> Full output: https://pastebin.mozilla.org/8868795
>> ___
>> dev-developer-tools mailing list
>> dev-developer-to...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-developer-tools
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Dump GC's retaining paths for any GC thing while debugging with JS::ubi::dumpPaths

[Nick Fitzgerald]

Hi everyone!

Friendly PSA: sometimes you're debugging a "leak" where the GC considers
something reachable and therefore won't collect it, and this happens at an
inopportune time for using the devtools memory panel (eg right before a
DESTROY_RUNTIME collection), so you can't use the nice GUI for visualizing
the GC's retaining paths.

Fear not! You can use `JS::ubi::dumpPaths` to log retaining paths of any GC
thing from within GDB, or you can compile it in as you might do with a
tactically placed printf.

The signature is `void JS::ubi::dumpPaths(JSRuntime* rt, JS::ubi::Node
node, maxRetainingPaths = 10)`. The `rt` should be the runtime that the
thing belongs to, `node` is the thing (JS::ubi::Node constructs from raw GC
pointers as well as Rooted and Handle), and `maxRetainingPaths` is the
number of retaining paths to dump.

Include the "js/UbiNodeShortestPaths.h" header to get `JS::ubi::dumpPaths`.

Happy bug hunting!

Example output:

Path 0:
0x7fff5fbfec10 JS::ubi::RootList
|
|
''
|
V
0x115c49d80 JSObject
|
|
'shape'
|
V
0x12ac4db50 js::Shape
|
|
'base'
|
V
0x116244e70 js::BaseShape
|
|
'ShapeTable shape'
|
V
0x116289120 js::Shape
|
|
'getter'
|
V
0x11627b3a0 JSObject
|
|
'private'
|
V
0x11855d940 JSObject
|
|
'script'
|
V
0x113290bf0 JSScript
|
|
'sourceObject'
|
V
0x1132763c0 JSObject

Full output: https://pastebin.mozilla.org/8868795
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: use nsresult& outparams in constructors to represent failure

[Nick Fitzgerald]

On Thu, Apr 21, 2016 at 3:24 AM, Nicholas Nethercote  wrote:

> On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva 
> wrote:
> > Fallible construction (even with a way to report failure) is annoying if
> > only because the object's destructor has to account for the possible
> > invalid states. I much prefer having a static creation method that will
> > only instantiate the object in case of success, and mark the constructor
> > protected. Something like:
> >
> > static
> > already_AddRefed Foo::Create(SomeParams...) {
> > // logic that may fail...
> > if (failed) {
> >  return nullptr;
> > }
> > return MakeAndAddRef(stuffThatDidNotFail);
> > }
>
> So instead of doing the infallible part in the constructor and the
> fallible part in the Init() function, you're suggesting doing the
> fallible part first and only calling the constructor once it succeeds?
> Interesting. I can see it would work nicely for some heap-allocated
> objects. But I see two possible problems:
>
> - It doesn't appear to work with stack-allocated objects?
>

​I think `mozilla::Maybe` works well, as mentioned elsewhere in the
thread. Here is an example of a non-boxed class whose ctor is infallible
and has a factory method returning a `Maybe` where​
​ `None` indicates failure: ​
https://dxr.mozilla.org/mozilla-central/rev/4feb4dd910a5a2d3061dbdd376a80975206819c6/js/public/UbiNodeDominatorTree.h#207-274

​In general I agree with Nicolas: use patterns that make half-constructed
things impossible and avoid the whole mess.​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Build System Project - Update from the last 2 weeks

[Nick Fitzgerald]

Is there a reason why we aren't using LTO?

On Fri, Apr 8, 2016 at 4:35 PM, Ted Mielczarek  wrote:

> No. GCC *has* an LTO optimizer, but we're not using it. We're just doing
> a PGO build. MSVC requires enabling LTO to use their PGO, so the
> resulting build has both.
>
> -Ted
>
> On Fri, Apr 8, 2016, at 05:08 PM, Jeff Gilbert wrote:
> > I thought Linux did LTO but not PGO?
> >
> > On Tue, Apr 5, 2016 at 3:53 PM, Mike Hommey  wrote:
> > > On Tue, Apr 05, 2016 at 09:02:09PM +0100, David Burns wrote:
> > >> Below is a highlight of all work the build peers have done in the
> last 2
> > >> weeks as part of their work to modernise the build infrastructure.
> > >>
> > >> Since the last report[1] a large number of improvements have landed in
> > >> Mozilla Central.
> > >>
> > >> The build system now lazily installs test files. Before, the build
> copied
> > >> tens of thousands of test and support files. This could take dozens of
> > >> seconds on Windows or machines with slow I/O. Now, the build system
> defers
> > >> installing test files until they are needed there (e.g. when running
> tests
> > >> or creating test packages). Furthermore, only the test files relevant
> to
> > >> the action performed are installed. Mach commands running tests
> should be
> > >> significantly faster, as they no longer examine the state of tens of
> > >> thousands of files on every invocation.
> > >>
> > >> After upgrading build machines to use VS2015, we have seen a decrease
> in
> > >> build times[2] for PGO on Windows by around 100 minutes. This brings
> PGO
> > >> times on Windows in line with that of PGO(Strictly speaking this is
> LTO)
> > >> times on Linux.
> > >
> > > Just a nit: strictly speaking Windows builds do PGO+LTO, Linux builds
> do
> > > PGO, but not LTO.
> > >
> > > Mike
> > > ___
> > > 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
> ___
> 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

Re: Coding style for C++ enums

[Nick Fitzgerald]

On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
birunt...@mohanathas.com> wrote:

> On 8 April 2016 at 18:10, Kartikaya Gupta  wrote:
> > Others?
>
> enum class OptionD {
>   SentenceCaseValues,
>   ThisWontBeConfusedWithOtherThings
>   // ... because you need to use OptionD::ThisWontBeConfusedWithOtherThings
> };
>

Strong +1 for enum classes. That way we don't need any more nasty prefixing
and can
​instead ​
rely on the compiler
​​
and type system.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: #include sorting: case-sensitive or -insensitive?

[Nick Fitzgerald]

Any reason not to adopt SpiderMonkey's check_spidermonkey_style.py? It
deals almost exclusively with header and include related things, and not
indent levels, line lengths, or other things that gecko style disagrees
with.

https://dxr.mozilla.org/mozilla-central/source/config/check_spidermonkey_style.py

"""

##
This script checks various aspects of SpiderMonkey code style.  The
current checks are as# follows.## We check the following things in
headers.## - No cyclic dependencies.## - No normal header should
#include a inlines.h/-inl.h file.## - #ifndef wrappers should have the
right form. (XXX: not yet implemented)#   - Every header file should
have one.#   - The guard name used should be appropriate for the
filename.## We check the following things in all files.## - #includes
should have full paths, e.g. "jit/Ion.h", not "Ion.h".## - #includes
should use the appropriate form for system headers (<...>) and#
local headers ("...").## - #includes should be ordered correctly.#   -
Each one should be in the correct section.#   - Alphabetical order
should be used within sections.#   - Sections should be in the right
order.#   Note that the presence of #if/#endif blocks complicates
things, to the#   point that it's not always clear where a
conditionally-compiled #include#   statement should go, even to a
human.  Therefore, we check the #include#   statements within each
#if/#endif block (including nested ones) in#   isolation, but don't
try to do any order checking between such
blocks.#
"""



On Mon, Mar 28, 2016 at 3:54 PM, Cameron McCormack  wrote:

> David Keeler:
> > The style guidelines at
> >
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
> > indicate that #includes are to be sorted. It does not say whether or not
> > to consider case when doing so (and if so, which case goes first?). That
> > is, should it be:
> >
> > #include "Foo.h"
> > #include "bar.h"
> >
> > or
> >
> > #include "bar.h"
> > #include "Foo.h"
>
> If you are preparing to make some changes to the Coding style document
> around #include order, can you also please prescribe (a) where system-
> includes get placed, e.g.
>
> #include "aaa.h"
> #include 
> #include "ccc.h"
> #include 
>
> or
>
> #include 
> #include 
> #include "aaa.h"
> #include "ccc.h"
>
> and (b) how includes with paths are sorted, e.g.
>
> #include "aaa.h"
> #include "bbb/bbb.h"
> #include "bbb/ccc/ddd.h"
> #include "bbb/eee/fff.h"
> #include "bbb/ggg.h"
> #include "ccc.h"
>
> or
>
> #include "bbb/ccc/ddd.h"
> #include "bbb/eee/fff.h"
> #include "bbb/bbb.h"
> #include "bbb/ggg.h"
> #include "aaa.h"
> #include "ccc.h"
>
> or some other order that makes sense.
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
> ___
> 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

Re: rr chaos mode update

[Nick Fitzgerald]

It seems like try/tbpl could automatically detect new test files and run
them N times. That way, the developer doesn't have to do it manually, so it
is less "intimidating" and also less likely to be skipped by accident or
forgotten.

Running under rr would be nice, but even without rr this seems like it
would be a nice addition to our testing infrastructure.

On Mon, Feb 15, 2016 at 11:59 PM, Axel Hecht  wrote:

> On 16/02/16 03:15, Kyle Huey wrote:
>
>> Seems like a good thing to expect developers to do locally today.
>>
>
> Two concerns:
>
> What's the successs criteria here?
>
> Also, speaking as an occasional code contributor, newcomers and folks like
> me will probably give up on contributing patches earlier.
>
> Axel
>
>
>> - Kyle
>>
>> On Mon, Feb 15, 2016 at 6:08 PM, Justin Dolske 
>> wrote:
>>
>> On 2/14/16 9:25 PM, Bobby Holley wrote:
>>>
>>> How far are we from being able to use cloud (rather than local) machine
>>>
 time to produce a trace of an intermittently-failing bug? Some one-click
 procedure to produce a trace from a failure on treeherder seems like it
 would lower the activation energy significantly.


>>> And with that... At some point, what about having all *new* tests be
>>> battle-tested by X runs of rr-chaos testing?  If it passes, it's allowed
>>> to
>>> run in the usual CI automation. If it fails, it's not (and you have a
>>> handy
>>> recording to debug).
>>>
>>> Justin
>>>
>>> ___
>>> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

On Sat, Jan 16, 2016 at 5:41 AM, Philip Chee  wrote:

> This is great! Is there a way of expanding/collapsing the whole tree?
> Thunderbird uses "\" (collapse) and "*" (expand).
>

​You can use ALT+click on an arrow to expand a​ whole subtree. However,
because after a certain depth we start incrementally loading sub-trees,
those incrementally loaded subtrees will not be auto-expanded. In general,
the dominator trees are too large to eagerly display in the UI; there is an
item in the tree for every node in the heap graph that we snapshot'd.



>
> Nitpick: The columns don't appear to be resizeable.
>
>
That is a pretty unfortunate screenshot. ​We have a bug in flight to ensure
that the columns are wide enough​:
https://bugzilla.mozilla.org/show_bug.cgi?id=1224201

If we can always ensure that the minimum cell size in the table is large
enough to display the number contained within, then I'm not convinced we
need resizing. Perhaps we can take this discussion to that bug, or a new
one?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

Reply inline below.

On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein  wrote:

> From your screenshot, there are a lot of instances of "objects > Array",
> "objects > Object", etc. Is the a way to display the variable name used for
> those objects?
>

​The node might not be in a JS variable (eg​ is a C++ implementation detail
that is not exposed to JS) or it might be referred to by many variables in
different parts of the JS code or it might be referred to not by any
variables in the JS code, but by something in the C++ world.

So, I think the "real" (or at least more general) solution is to show the
first N shortest paths from the GC roots to the thing. This is the next
feature I will be working on for the memory tool. I wanted to do dominator
trees first because it tells you which objects to pay attention to; the
shortest paths will tell you more about how a specific object is kept
alive. It didn't make sense to do the latter before the former.

Stay tuned!


> Also, what is the plan for making tools like the Memory view appear in a
> default install? In other words, without having to go to the Settings. I
> worry that users may not know to click on the Settings and just think that
> other browsers offer more tools than we do.
>

​This is a good conversation to have, but I don't have any good answers. We
have a lot of panels in the devtools, many of which are fairly niche, and
it isn't clear how to simultaneously give them visibility and not overwhelm
users.

Console, debugger, performance: these panels are ​a clear "always show" to
me. The web audio tool is very niche and so I don't think it would make
sense to show it by default. The memory tool falls in between in my mind.
I'm open to suggestions!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

Hi folks!

Dominator trees give you fine-grained insight into memory retention.

In a graph rooted by some node R, a node A is said to dominate B iff every
path to B starting from R passes through A. In the context of a heap graph,
another way to say this would be that A is retaining B: if the garbage
collector found A to be unreachable and eligible for reclaiming, than B
would also be unreachable and eligible for reclaiming.

We also use this to calculate the "true" memory cost of a node in the heap
graph. This is the "retained size" and contrasts with the naive "shallow
size". For example, imagine a large binary tree where there are no outside
references into subtrees, only to the root. The root node itself has a
small shallow size: a left branch pointer, a value, and a right branch
pointer. However, it is retaining the whole rest of this large tree's
structure, and so its retained size is significant.

Here is a screenshot of the dominator tree (combined with allocation stack
tracking) in action to debug the memory overhead of loading large source
files in a CodeMirror editor: http://i.imgur.com/sGsVJb9.png

And here is a reminder of how to enable to memory tool within the devtools:
http://i.imgur.com/hEPTqrT.png

If you would like to use this tool for the whole runtime rather than scoped
to a single tab, use the browser toolbox. Here are instructions for
enabling and using the browser toolbox:
https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Please try it out, give me your feedback, and file bugs in the "Firefox"
product and "Developer Tools: Memory" component!

My thanks to the folks who reviewed patches for this feature: Jordan
Santell, Steve Fink, Boris Zbarsky, and Jim Blandy.

Cheers,

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New heap snapshots tool in the developer tools

[Nick Fitzgerald]

​On Wed, Nov 4, 2015 at 11:07 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:

> That sounds very useful.
>
> Any chance we can get the same kind of output on the console in case of
> mochitest memory leak?
>

​I've filed ​https://bugzilla.mozilla.org/show_bug.cgi?id=1221704 to track
this.

​You can use `[ThreadSafe]Chrome​Utils.saveHeapSnapshot`[0] to
programmatically save a heap snapshot file. This tool is using that under
the covers right now, but we don't yet expose importing and exporting these
files in the UI. It is pretty high priority to add soon.

Follow along with import and export at
https://bugzilla.mozilla.org/show_bug.cgi?id=1215954 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1215953

So yes, we could definitely programmatically save a heap snapshot file at
the end of a mochitest if we detect a leak. A tiny bit more work needed on
the tool's frontend to import a saved snapshot.

​[0] ​
h
​​
ttps://
dxr.mozilla.org/mozilla-central/rev/f742b9412ed5aace90ad863b276faae0641090a8/dom/webidl/ThreadSafeChromeUtils.webidl#13-25,36-66
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New heap snapshots tool in the developer tools

[Nick Fitzgerald]

Hi folks!

(Jordan Santell made an announcement on the devtools mailing list[0], but I
thought I'd spread the word around.)

The first iteration of the new heap snapshots memory tools landed on m-c in
the middle of the last cycle and rode the train to Developer Edition with
the merge.

This tool is built on top of JS::ubi::Node[1] which is an API to do
analyses on the heap graph as the GC sees it, and the SavedFrame JS stack
recording[2].

In this first release, the most notable feature is capturing the JS stack
when objects are allocated so that you can see exactly where your retained
objects are coming from. The downside is that this incurs overhead and you
have to start recording allocation stacks *before* you start saving heap
snapshot. You can also disect the heap into various other buckets.

http://i.imgur.com/QrcrtWq.png

This initial version is very much just getting something out the door and
there is a ton more coming down the pipe. Filtering/searching and diffing
snapshots are in the works at the moment. Currently, we don't take
advantage of our full access to every node and edge in the heap graph.
Soon, we will compute dominator trees to find "deep" size / retention as
well as find the first N shortest paths from GC roots to objects of
interest. We are also planning on adding support for cycle collected nodes
and edges to the JS::ubi::Node graph.

You can enable the new tool by going to the settings panel of the devtools
and checking the "Memory" checkbox on the left underneath "Default Firefox
Developer Tools".

http://i.imgur.com/hEPTqrT.png

If you would like to use this tool for the whole runtime rather than scoped
to a single tab, use the browser toolbox. Here are instructions for
enabling and using the browser toolbox:
https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Please try it out and file bugs in the "Firefox" product and "Developer
Tools: Memory" component! We want this to be a useful tool for _you_!

Thanks,

Nick

[0]
https://groups.google.com/d/msg/mozilla.dev.developer-tools/TIehyWbmXiQ/g-iLjF3eAgAJ

[1]
https://dxr.mozilla.org/mozilla-central/rev/59a6ad6a921f4809dfc37d943d765300c65721e5/js/public/UbiNode.h#31-163

[2]
https://dxr.mozilla.org/mozilla-central/rev/59a6ad6a921f4809dfc37d943d765300c65721e5/js/src/vm/SavedStacks.h#21-148
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Nick Fitzgerald]

Note that for JS objects (and JS strings very soon), you can track
allocation stacks with the Debugger API:

https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory

On Thu, Sep 17, 2015 at 10:55 AM, Andrew McCreight 
wrote:

> On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight 
> wrote:
>
> >
> >
> > On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart 
> > wrote:
> >
> >> Good stuff!
> >>
> >> I hope you'll consider tracking AddRef's and Release's as well.
> >>
> >> I recently experimented with that for a troubled RefCounted class [1],
> >> and it was very useful to find which AddRef didn't have its
> corresponding
> >> Release.
> >>
> >
> > There's already refcount logging for this:
> >   http://www-archive.mozilla.org/performance/refcnt-balancer.html
> >
> >
> Olli points out that I should actually link to the more modern page for
> this:
>
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Refcount_tracing_and_balancing
>
> Anybody who wants help with refcount logging should feel free to get in
> touch with me and I can help walk them through it.
>
>
> > It is generally too spammy to include in the TreeHerder log, but it can
> be
> > useful.
> >
> > Andrew
> >
> >
> >
> >>
> >> Cheers,
> >> Gerald
> >>
> >> [1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
> >> ___
> >> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GTK3 linux builds

[Nick Fitzgerald]

One more group of defectors within Mozilla. From the DevTools coding
standards[0]:



   - aArguments aAre the aDevil (don't use them please)



Although, there are still some files in tree with the legacy style.

[0] https://wiki.mozilla.org/DevTools/CodingStandards#Code_style

On Tue, Jul 7, 2015 at 8:00 AM, chad.mil...@canonical.com wrote:

 On Tuesday, June 16, 2015 at 5:12:17 PM UTC-4, Mike Hommey wrote:
  On Tue, Jun 16, 2015 at 04:16:13PM -0400, Jeff Muizelaar wrote:
   We're working on making all of the tests green for GTK3. This means
   that we could be changing the default linux configuration to GTK3 as
   early as FF42. If anyone has any reasons for us not to make this
   change it would be good to know now. FWIW, I believe Fedora is already
   shipping GTK3 builds of Firefox.
 
  I depends on what our target GTK3 version would be. If, as recently
  suggested, we go with 3.14 as the minimum supported, that's fairly
  new (9 months old), and switching our builds to GTK3 would make us
  drop support for a lot of people that use older systems.
 
  I thought we'd be shipping both GTK2 and GTK3 builds for a while.
 
  Mike


 In Ubuntu, we don't have a strong preference for Gtk2 versus Gtk3, but it
 is important for us to support Gtk-3.4. We are obligated to keep Ubuntu
 12.04 updated for a while still. So, if you don't change the current
 library versions on Mozilla's test machines, I'm happy.

 Please keep dependencies to Gtk-3.4 at latest.

 - chad
 ___
 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

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Nick Fitzgerald]

(Posted this reply to the wrong thread, reposting to the right one... _)

One more group of defectors within Mozilla. From the DevTools coding
standards[0]:



   - aArguments aAre the aDevil (don't use them please)



Although, there are still some files in tree with the legacy style.

[0] https://wiki.mozilla.org/DevTools/CodingStandards#Code_style

On Tue, Jul 7, 2015 at 6:57 AM, Kartikaya Gupta kgu...@mozilla.com wrote:

 On Tue, Jul 7, 2015 at 9:18 AM, Honza Bambas hbam...@mozilla.com wrote:
  I'd be happy to support
  removing the prefix if people also commit to splitting any giant
  functions they touch as part of the prefix removal.
 
 
  That's (sorry) non-sense.  In almost all cases longer methods/functions
  cannot be just split.  It would probably make the code just much harder
 to
  read and maintain (with a lot of new arguments missing the 'a' prefix ;))
  and is not necessary.  Not an argument IMHO.

 Can you point me to a couple of examples of long functions that you
 think cannot be split reasonably? I'm curious to see what it looks
 like. Obviously functions with giant switch statements and the like
 are exceptions and should be treated exceptionally but I would like to
 see some regular functions that can't be split.

 Cheers,
 kats
 ___
 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

Re: Announcing the Content Performance program

[Nick Fitzgerald]

On Sun, Jun 28, 2015 at 5:14 PM, Nathan Froyd nfr...@mozilla.com wrote:

 On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote:
 
  BTW, wasn't there an effort a few couple years ago, to move content
  event loop in different threads for different tabs? What happened to
  that?
 

 If you are referring to bug 715376 (and related), those patches are still
 in my queue, fully rebased.  We only need to decide that it's worth
 spending a significant amount of time addressing the test failures induced
 by those patches (see comment 109 in that bug, for instance) and the
 possible webcompat issues from those patches.


​It is awesome to hear that you have those patches rebased. I really hope
we push forward with that.

In addition to the potential benefits listed in that bug, the JS debugger
currently has a lot of issues where suppressing a page's events doesn't
actually suppress everything (Promises, postMessage, XHR, I think a couple
others) and so JS can still run while you are paused. Being able to use a
debugger/chrome dedicated event queue would nicely solve all these cases in
one swoop.​ See https://bugzilla.mozilla.org/show_bug.cgi?id=1074448 for
more.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing the Content Performance program

[Nick Fitzgerald]

From your blog post:

 Heavy activity in background tabs badly affects desktop Firefox’s
scrolling performance1 (much worse than other browsers — we need E10S)

I was under the impression that because e10s is only a single process for
all content (at least right now) a background tab can still negatively
affect the foreground tab.

Have we ever considered building something like the unload tab addon into
the platform or Firefox directly? I know we do some throttling of timeouts,
but perhaps we should also consider this heavier handed approach when there
are many tabs open.

https://addons.mozilla.org/en-US/firefox/addon/unloadtab/


An essential add-on for power users that have many tabs open. Curb your
resource usage by unloading tabs that you haven't visited for a while. An
unloaded tab is restored back to its original state when you need it again.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: DXR 2.0 staged. Feedback please!

[Nick Fitzgerald]

Looking forward to eventually getting better JS searching via the
multi-language support!

What is the relative priority of permalinks to specific revisions?

On Wed, Jun 3, 2015 at 12:10 PM, Erik Rose e...@mozilla.com wrote:

 DXR 2.0 is about to land! This is a major revision touching every part of
 the system, swapping out SQLite for elasticsearch, and replacing many
 hard-coded C++ assumptions with a language-independent plugin interface.

 Please take it for a spin on the staging server at http://dxr.allizom.org/,
 and see if you find any regressions from the production version at
 dxr.mozilla.org. You can file them directly at
 https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtoolscomponent=DXRstatus_whiteboard=es
 or just reply. Barring showstoppers, we plan to put it into prod within a
 few weeks.

 What's new?

 * Improved C/C++ analysis
 * Multi-language support—Python and Rust, for starters, soon to be enabled
 for moz-central
 * All queries are fast—and will be even faster in prod, once our webheads
 and elasticsearch servers are colocated
 * Browsing of images
 * Listing of binary files
 * Result counts (so jrudermann can have googlefights)
 * Independent tree indexing, so one build failure won't scuttle updates
 for the rest of the trees. (This will help us get all the trees currently
 under MXR indexed.)
 * Parallel indexing so we can set the DC on fire
 * New plugin architecture so we can add new languages, query types, and
 cross references easily (
 https://dxr.readthedocs.org/en/es/development.html#writing-plugins)

 This is really a backend-focused release, but you can see some of the new
 possibilities start to leak out. I'm enthusiastic about the features this
 will enable next: better surfacing of symbols without having to know their
 type ahead of time, faceted drill-down, context for search results, and
 permalinks (our last major blocker to decommissioning MXR).

 Thanks for helping test it out!

 Erik Rose
 DXR Lead
 ___
 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

Re: Announcing Operation Instrument

[Nick Fitzgerald]

This is built on top of the docshell ProfileTimelineMarkers. There is a
marker for the start of the traced operation and another for the end of the
traced operation.

The RAII class mozilla::AutoTimelineMarker simply adds these start and end
markers on construction and destruction respectively (but only if the given
docshell is being observed by devtools).

On Mon, Apr 27, 2015 at 7:17 PM, Robert O'Callahan rob...@ocallahan.org
wrote:

 How is this related to PROFILER_LABELs, docshell ProfileTimelineMarkers,
 and VisualEventTracer?

 Rob
 --
 oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
 owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
 osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
 owohooo
 osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
 oioso
 oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
 owohooo
 osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
 ooofo
 otohoeo ofoioroeo ooofo ohoeololo.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing Operation Instrument

[Nick Fitzgerald]

Wow. Email formatting fail. Hopefully this turns out a little better:


Hello platform hackers!

[Operation Instrument](https://wiki.mozilla.org/DevTools/OperationInstrument)
is a project that aims to add tracing instrumentation to Gecko and provide
a holistic view of where time is being spent and why.

Examples of traced operations include:

* Style Recalculation
* Layout Reflow
* Painting
* JavaScript Run-to-Completion
* Etc.

The traced operations are displayed in the DevTools Performance panel's
timeline: https://wiki.mozilla.org/File:Timeline-screenshot.png

The goal is to have zero gaps between markers, so that we can always tell
at a high level what Gecko is doing, and what brought it there.

But, the DevTools team can't do it alone. You can help add new
instrumentation to the parts of Gecko you're familiar with. If you have an
nsDocShell, it can be as easy as using a simple RAII class:
`mozilla::AutoTimelineMarker`. There is a quick and easy tutorial with
examples here:
https://wiki.mozilla.org/DevTools/OperationInstrument#Tutorial:_Instrumenting_New_Operations

Additionally, when you are implementing new features, please consider
adding instrumentation right off the bat!

Please take a look at the blockers of our meta bug, and file new bugs that
block it: https://bugzilla.mozilla.org/show_bug.cgi?id=1145271

Thanks,

Nick (and the whole DevTools team)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Announcing Operation Instrument

[Nick Fitzgerald]

Hello platform hackers!​

​[​
Operation Instrument
​]
(htt
​​
ps://wiki.mozilla.org/DevTools/OperationInstrument)​
is a project that aims to add tracing instrumentation to Gecko and provide
a holistic view of where time is being spent and why.

Examples of traced operations include:

*
​
​ ​
Style Recalculation
*
​Layout ​
Reflow
* Painting
*
​ ​
JavaScript
​R​
un-to-
​C​
ompletion
​*​
​ ​
Etc.

The traced operations are displayed in the DevTools
​​
Performance
​​
​panel​
's timeline:​​ ​https://wiki.mozilla.org/File:Timeline-screenshot.png

​The goal is to have zero gaps between markers, so that we can always tell
at a high level what Gecko is doing, and what brought it there.​


​But​
​, the DevTools​
​ team can't do it alone. You can help add new instrumentation to the parts
of Gecko you're familiar with. If you have an nsDocShell, it can be as easy
as using a simple RAII class: `mozilla::AutoTimelineMarker`. There is a
quick and easy tutorial with examples here:
https://wiki.mozilla.org/DevTools/OperationInstrument#Tutorial:_Instrumenting_New_Operations

​Additionally, when you are implementing new features, please consider
adding instrumentation right off the bat!

Please take a look at the blockers of our meta bug, and file new bugs that
block it: https://bugzilla.mozilla.org/show_bug.cgi?id=1145271

​Thanks,

Nick (and the whole DevTools team​
​)​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Excessive inbound bustage

[Nick Fitzgerald]

On Tue, Apr 21, 2015 at 3:22 PM, Bobby Holley bobbyhol...@gmail.com wrote:

 It's not about making mistakes - it's about being mis-calibrated with
 respect to the rest of the development community. And it's not about
 shaming - it's about making people (both the developer and others) aware of
 these mismatches so that they can be corrected.


​And this can surely be done via private channels​, without public shaming
and the potential negatives people have listed elsewhere in the thread,
right?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Excessive inbound bustage

[Nick Fitzgerald]

On Tue, Apr 21, 2015 at 3:39 PM, Bobby Holley bobbyhol...@gmail.com wrote:

 On Tue, Apr 21, 2015 at 3:32 PM, Nick Fitzgerald nfitzger...@mozilla.com
 wrote:



 ​And this can surely be done via private channels​, without public
 shaming and the potential negatives people have listed elsewhere in the
 thread, right?


 How, exactly?I want the ability to see where I match up against my peers.
 Names are important here, and anonymization does a disservice to my
 interpretation of the data. Seeing names on try score of people I know are
 doing similar kinds of work is very helpful to gauge my relative usage.


​I imagine that we could show mean/median/percentiles/whatever, but you're
right that if you want to specifically compare with another person you
can't have anonymized data.​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The e10s throbber

[Nick Fitzgerald]

Yes they are built on the same SPS profiler backend.

However, the gecko profiler addon will do things the builtin devtools
can't, like open a shell and call `atos` to symbolicate C++ function
addresses.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1132529 for some context.

For the time being, I would recommend using the gecko profiler addon for
debugging chrome and platform performance issues.

On Wed, Apr 8, 2015 at 1:59 AM, Gijs Kruitbosch gijskruitbo...@gmail.com
wrote:

 On 07/04/2015 23:41, Robert O'Callahan wrote:

 On Wed, Apr 8, 2015 at 6:27 AM, Gavin Sharp ga...@gavinsharp.com wrote:

  We don't have telemetry yet. I've done some measurements and haven't

 found

 any cases where tab switching consistently takes longer in e10s.
 However,
 it's certainly possible that it does on average. Either way, it's hard
 to
 investigate until we can reproduce the problem.


 I see the spinner far too frequently. e10s tab switching is definitely
 far worse than non-e10s for me. I can reproduce it fairly
 consistently, though the STR seem to require loading my normal
 many-tab session and frequent heavy use, so it's hard to reduce to
 something easily replicable. How can I usefully debug this?


 Install the Gecko Profiler extension if you haven't already, and profile
 your tab switching.


 Is there any advantage in doing this over using the builtin devtools
 browser toolbox's profiling tools? I thought they used the same APIs and
 just visualized differently?

 ~ Gijs


 ___
 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

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

[Nick Fitzgerald]

On Tue, Mar 31, 2015 at 9:30 AM, Andrew Halberstadt 
ahalberst...@mozilla.com wrote:


 ​For example, we may implement a way to run all tests with a given tag
 across multiple different suites.


​Does this mean that I can't do `./mach​ test --tag foobar` to run both
xpcshell and mochitests tagged with foobar yet? Do I have to do `./mach
xpcshell-test --tag foobar` and `./mach mochitest-whatever --tag foobar`
separately?

Anyways, this looks like a very cool capability. Looking forward to using
it!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JavaScript code coverage

[Nick Fitzgerald]

I recommend reading
https://developer.mozilla.org/en-US/docs/Tools/Debugger-API or
js/src/doc/Debugger/ for more information.

On Tue, Jan 20, 2015 at 1:29 PM, Nick Fitzgerald nfitzger...@mozilla.com
wrote:

 ​On Mon, Jan 19, 2015 at 12:36 PM, Joshua Cranmer [image: ] 
 pidgeo...@gmail.com wrote:

 Getting good code coverage (line and branch coverage) ultimately requires
 fine-grained instrumentation (ideally bytecode-level) not presented by the
 current Debugger.



 ​I think you can get fine-grained enough data with the existing Debugger
 API by doing the following:

 * Adding all existing globals as debuggees: `Debugger.prototype.
 addAllGlobalsAsDebuggees`

 * Adding new globals as debuggees: have your Debugger's onNewGlobal hook
 to always add the new global as a debuggee.

 * For each `Debugger.Script` (on initialization via
 `Debugger.prototype.findScripts` and on new scripts in the future via the
 `onNewScript` hook):

 *** Use `Debugger.Script.prototype.getAllOffsets`​ to get all byte code
 offsets which are entry points to each line in the script

 *** Set a breakpoint on each of those offsets which, when hit, records
 that the offset's line was executed


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JavaScript code coverage

[Nick Fitzgerald]

​On Mon, Jan 19, 2015 at 12:36 PM, Joshua Cranmer  pidgeo...@gmail.com
wrote:

 Getting good code coverage (line and branch coverage) ultimately requires
 fine-grained instrumentation (ideally bytecode-level) not presented by the
 current Debugger.



​I think you can get fine-grained enough data with the existing Debugger
API by doing the following:

* Adding all existing globals as debuggees: `Debugger.prototype.
addAllGlobalsAsDebuggees`

* Adding new globals as debuggees: have your Debugger's onNewGlobal hook to
always add the new global as a debuggee.

* For each `Debugger.Script` (on initialization via
`Debugger.prototype.findScripts` and on new scripts in the future via the
`onNewScript` hook):

*** Use `Debugger.Script.prototype.getAllOffsets`​ to get all byte code
offsets which are entry points to each line in the script

*** Set a breakpoint on each of those offsets which, when hit, records that
the offset's line was executed
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Compiling m-c within Emacs (was: Re: Good ways to view Firefox compile errors in a terminal?)

[Nick Fitzgerald]

​On Tue, Jan 13, 2015 at 10:01 AM, Nathan Froyd nfr...@mozilla.com wrote:

 On Tue, Jan 13, 2015 at 11:52 AM, Nick Fitzgerald nfitzger...@mozilla.com
  wrote:

 For those of us using Emacs:

 I use M-x shell as my terminal, and when combined with
 compilation-shell-minor-mode, I get the following goodies:


 FYI, you can use M-x compile (or at least a wrapper around it) with a bit
 of cleverness:

 (defun froydnj-build-mozilla-with-mozconfig (mozconfig target)
   (let* ((objdir (shell-command-to-string
   (format grep MOZ_OBJDIR %s | cut -f 2 -d = mozconfig)))
  ;; Use the first cd command so compile's intelligent setting of
  ;; default-directory works to our advantage.  Use the second cd
  ;; command so mach is invoked from the correct directory.
  (compile-command (format cd %s; cd %s; env MOZCONFIG=%s mach
 --log-no-times build %s
   (remove-if #'(lambda (x) (char-equal x
 ?\n))
  objdir :from-end t :count 1)
   froydnj-mozilla-srcdir
   mozconfig
   target)))
 (compile compile-command)))

 This gets invoked from some machinery to choose which mozconfig (six
 different mozconfigs so far, full builds or binaries builds), but the
 idea should be clear.  By setting compilation-buffer-name-function
 appropriately, separate mozconfigs produce their compilation output in
 separate buffers, and one can avoid cluttering up shells with compilation
 output.

 -Nathan


I have my own compile function that I bind to C-c C-c, that uses the shell
buffer instead of the compilation buffer (I prefer to have it all
integrated in one place):

(defun clear-shell-buffer ()
  (interactive)
  (let ((comint-buffer-maximum-size 0))
(comint-truncate-buffer)))

(defun my-compile (cmd)
  (interactive
   (list (compilation-read-command compile-command)))
  (if (get-buffer *shell*)
  (switch-to-buffer-other-window *shell*)
(shell))
  (clear-shell-buffer)
  (end-of-buffer)
  (comint-kill-input)
  (insert cmd)
  (end-of-line)
  (comint-send-input)
  (unless (equal cmd (eval compile-command))
(setq compile-command cmd)))

The first time you compile, you have to enter the compilation command:

  C-c C-c ./mach build subdir RET

But after that, the cmd is remembered and you can simply do:

  C-c C-c RET
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is anyone still using JS strict warnings?

[Nick Fitzgerald]

I generally don't find them useful, but instead annoying, and that they
provide a lot of noise to filter out to find actual relevant errors. This
is including the undefined property errors. It is a common JS style to pass
around configuration/option objects that will be missing many properties
that get accessed by functions they are passed to. My understanding is that
part of this is special cased not to generate these messages, but in my
experience it isn't close to enough.

At minimum, we should mark them all JSEXN_NONE in js.msg so that they don't
appear as misleading ReferrenceError or whatever other kind of error.

​We also shouldn't call them strict errors, since they have nothing to do
with strict mode.​


Additionally, whether these messages show up depends on how the JS is
loaded. I haven't looked at the specifics in a while, but IIRC it depended
upon whether you were using JSMs or Cu.evalInSandbox, etc. We have tests in
devtools that fail if there are any errors in the console, and so changing
the way we load JS sources with no other changes to the code, results in
tests breaking for perfectly good code. It can be *very* frustrating.

I'm like the idea of providing optional JS Hint style linting with these
messages, but it isn't really optional right now, and even if you don't
want these messages, they are still forced upon you.

Personally, I'm A-OK with retiring these messages, but it seems at least
some people do get value from them. Maybe this should be a flag?
--enable-extra-js-warnings? A pref?

Just not enabled by default, please...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform