Closed Bug 1028246 Opened 8 years ago Closed 8 years ago

Add a way to trace program allocation behaviour


(Core :: JavaScript: GC, defect)

Not set





(Reporter: jonco, Assigned: jonco)




(1 file, 1 obsolete file)

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.
Attached patch gc-trace (obsolete) — Splinter Review
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:
Attachment #8443536 - Flags: feedback?(terrence)
Comment on attachment 8443536 [details] [diff] [review]

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.
Attachment #8443536 - Flags: feedback?(terrence) → feedback+
Attached patch gc-trace v2Splinter Review
Updated trace framework, now outputs information about object classes among other things.
Attachment #8443536 - Attachment is obsolete: true
Attachment #8447141 - Flags: review?(terrence)
Comment on attachment 8447141 [details] [diff] [review]
gc-trace v2

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

Attachment #8447141 - Flags: review?(terrence) → review+
sorry had to backout for 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
Fixed separate issue with unified builds and relanded:
Depends on: 1032171
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.