934022 - Find references for GC'd objects

Status: NEW

(DevTools :: Memory, defect, P3)

Description

[Axel Kratel]

As an app/web developer, I would like to find where my app produces objects that get GC'd so that I can minimize the number of GC events while my app is running.

Acceptance Criteria:
- When a GC event occurs, I should be able to see the objects being collected and where they were created and where they were released.
- do this in a heap/profile recording

Comment 1

[David Bruant]

(In reply to Axel Kratel from comment #0)
> - When a GC event occurs, I should be able to see the objects being
> collected and where they were created and where they were released.
I wonder if we have this sort of event/info available now. If not, it might be some non-trivial work to get it. Needinfo'ing someone who probably have the answer.

Comment 2

[Andrew McCreight [:mccr8]]

There's nothing like that that I know of.  There's some kind of setObjectMetaDataCallback infrastructure in place intended to support tracking where objects were allocated, but it isn't used yet as far as I know.  jimb was going to look into that, I think.

Note that tracking when objects go away will be more difficult and likely involve a performance penalty once we move to some kind of moving generational garbage collector.

Comment 3

[Andrew McCreight [:mccr8]]

We do have DumpHeapComplete which produces a textual representation of the entire JS heap, which is a sort of a snapshot, but the view is low-level and isn't really something a non-Gecko developer would want to deal with.

Comment 4

[Axel Kratel]

Leave in the backlog for now until we have a better handle on any sort of implementation path. Will need to do some investigation.

Comment 5

[Julien Wajsberg [:julienw]]

Hey Paul, do you think this is something that could be easily added to the GC markers we have for perf.html ?

Comment 6

[Paul Bone [:pbone]]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Hey Paul, do you think this is something that could be easily added to the
> GC markers we have for perf.html ?

I'd love to see this feature and when speaking to App developers I've heard similar things.  Right now developers can measure memory usage but don't know how to profile it (finding relevant hot spots).

I'm interested in this because if we can provide it and make it good and easy to use then web apps will use less memory on _any_ browser.  That's good for everyone.

> Acceptance Criteria:
> - When a GC event occurs, I should be able to see the objects being collected and where they were created 

This is possible, but it will add extra memory usage (one extra word per object) so we wouldn't want to use it unless profiling.  Each object would need an additional pointer referring to its allocation site.  Once we have that we could generate information during a collection about the most prolific allocation sites and what percentage of their allocations became garbage (that the GC found this cycle).

> ...and where they were released.

Ouch.  We won't do that.  This is so difficult/costly it's infeasable.  It's so infeasable I'm gonna say it's impossible.


Generally speaking there are a few pointers I'd like to provide here, if you can think of how to show them in the profiler and in devtools then that'd be great.

 * High allocation rates and lots of garbage is not a bad thing.  Just because the GC is doing lots of work doesn't mean things arn't running well.  A lot of non-GC engineers seem to disagree with me about this, FWIW.  But nursery allocation is fairly inexpensive.  Nursery sweeping is _very_ cheap.  So allocating objects that die in the nursery is fine.  If you see lots of GCMinor events in the profiler but there's a very low promotion (aka tenure) percentage, then that's fine.  See also Bug 1433007 where I hope to tune the GC more for this situation.

 * Not collecting memory that won't be used is bad.  Just because there's a GC, even the most accuruate most aggressive GC, doesn't mean you won't get memory leaks.  If a program allocates memory, doesn't use it ever again but keeps a reference to it - the GC can't do anything about it.  (Actually, some GCs may be able to detect it and move it to a special area of the heap where it is managed differently and doesn't cost as much to mark.  But it still takes up memory (or swap)).

 * Allocations that die in the tenured heap have a cost.  I just said not to worry about high allocation rates, that's mostly for the nursery.  High allocation and death in the tenured heap does have a cost.  The worst is if something dies soon after being promoted into the tenured heap.  Then we traded it and moved it and had we waited to do that nursery collection we could have avoided that work.  I'm looking at Bug 1467697 at the moment which could be a case of this, or related where there are lots of tenured->nursery pointers.  I don't know yet and things like Bug 1473213 will help me find out.

I wonder how easilly we can show in the profiler and/or devtools which situations arn't a big deal and which are.  Particularly that first one "OMG there are SO MANY MinorGC events!"  (if the events are fast and very little memory is tenured, then don't stress about them).