1028246 - Add a way to trace program allocation behaviour

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect)

Description

[Jon Coppeard (:jonco)]

To help with tuning the GC, add a way of running the JS engine that produces a trace of relevant GC events (at least allocation and finalization).  This can then be postprocessed to generate information about where objects are being allocated (i.e. in the nursery or the tenured heap) and what their lifetimes turn out to be.

This will allow us to see for example whether we are allocating objects in the right place, and hopefully show us where there opportunities for improvement.

Comment 1

[Jon Coppeard (:jonco)]

Attachment: gc-trace

Here's a patch to add tracing to the engine, and utility to postprocess the data.

To use it you need to configure the engine with --enable-gc-trace and supply the environment variable JS_GC_TRACE=file.  An appropriate zeal mode is also necessary to get accurate information about lifetimes, for example 2,10.

Unfortunately it seems that we free and regenerate a great many JitCode objects with this setting, even though I changed shouldPreserveJitCode() to return true while we're tracing.  I'm still investigating this, but it doesn't seem to affect the results much apart from this anomaly.

I ran this setup on the octane benchmarks and made a web page to display the results, which I put up here: 

http://people.mozilla.org/~jcoppeard/gcstats/

Comment 2

[Terrence Cole [:terrence]]

Comment on attachment 8443536 [details] [diff] [review]
gc-trace

Review of attachment 8443536 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/gc/GCTrace.cpp
@@ +13,5 @@
> +
> +using namespace js;
> +using namespace js::gc;
> +
> +static FILE *gcTraceFile = nullptr;

This will work fine for the shell and I think running the browser in zeal mode is not feasible at the moment, so this is probably fine in general. If we do ever want to support the browser, moving this to the gcruntime and making unique filenames should not be hard.

Comment 3

[Jon Coppeard (:jonco)]

Attachment: gc-trace v2

Updated trace framework, now outputs information about object classes among other things.

Comment 4

[Terrence Cole [:terrence]]

Comment on attachment 8447141 [details] [diff] [review]
gc-trace v2

Review of attachment 8447141 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

Comment 5

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/445dd051b6af

Comment 6

[Carsten Book [:Tomcat]]

sorry had to backout for https://tbpl.mozilla.org/php/getParsedLog.php?id=42749027&tree=Mozilla-Inbound bustage 

builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jsfun.cpp:768:11: error: reference to 'Range' is ambiguous
/builds/slave/m-in_l64-d_sm-ggc-000000000000/objdir/dist/include/mozilla/Range.h:19:7: error: candidates are: template<class T> class mozilla::Range
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jit/MIR.h:35:7: error: class js::jit::Range
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jsfun.cpp:768:11: error: 'Range' does not name a type
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jsfun.cpp:769:33: error: 'srcChars' was not declared in this scope
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jsfun.cpp:1744:5: error: reference to 'Range' is ambiguous
/builds/slave/m-in_l64-d_sm-ggc-000000000000/objdir/dist/include/mozilla/Range.h:19:7: error: candidates are: template<class T> class mozilla::Range
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jit/MIR.h:35:7: error: class js::jit::Range
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jsfun.cpp:1744:11: error: expected primary-expression before 'const'
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jsfun.cpp:1744:11: error: expected ';' before 'const'
/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/js/src/jsfun.cpp:1749:31: error: 'chars' was not declared in this scope

Comment 7

[Jon Coppeard (:jonco)]

Fixed separate issue with unified builds and relanded:

https://hg.mozilla.org/integration/mozilla-inbound/rev/cce12fad5b86

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/cce12fad5b86