519567 - add nested recording

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Luke Wagner [:luke]]

This bug proposes adding the ability to nest recorders.  Each recorder is a TraceRecorder object that compiles a single Fragment in a single tree.  Nesting would allow us to continue recording, instead of aborting, (1) an outer tree when an inner tree tries to grow, (2) a nested call to js_Invoke (as part of bug 517174).  This bug will work on (1) (dvander says this occurs often in v8-early-boyer), in preparation for (2).

The approach will be to introduce a new type/object "recorder stack" which maintains a stack of TraceRecorders and allows:
 - the top recorder to be suspended and a new recorder pushed on top
 - the top recorder to be popped and given to the recorder below for merging
 - all recording to be aborted

Most code should stay the same, working implicitly with the top TraceRecorder.

Comment 1

[Luke Wagner [:luke]]

Attachment: WIP v.1

WIP. This code sets up the framework necessary to have multiple recorders, and not have them stab each other in the face.  Most of the work was just determining what is being shared (and finding bug 520311 and bug 520323).  One major change is that the patch replaces the single shared JSTraceMonitor::lirbuf and ::traceAlloc objects with a pool of lirbufs and traceAllocs that are taken and returned by individual TraceRecorders.  The big piece left to do is implementing the merging logic that happens after an inner tree finishes recording.

The patch also does a little cleaning, making as many TraceRecorder members const as I could (there are a lot), since this helps thinking about multiple recorders, and shrinking the public interface of TraceRecorder a bit.

Comment 2

[Luke Wagner [:luke]]

In working through this, I found that there is a good bit of work to do:
 - there can be N tree calls between the outer recorder and where the exit which we would like to extend occurred; to avoid aborting recorders, we possibly need to start a recorder from each inner tree in working inside to outside.
 - after an inner recorder completes, we may need to do ExecuteTree, and record again, ... until we eventually are finished with the inner loop

To justify doing all this, it would be good to know first how much time we are currently wasting (on v8, e.g.) on recording sessions that get aborted for lack of nested recording.  I filed bug 521038, which should make the potential for speedup eminently clear.  Will comment again with results.

Comment 3

[Luke Wagner [:luke]]

WONTFIX so long as we don't have cases where serious time is wasted.