596260 - JIT Support for exact or partly-exact stack scanning

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect)

Comment 1

[Edwin Smith]

Goal is to allow exact marking of JIT-generated stack frames.

Starting to frame the problem: there are points in the method where we must record enough information to support an exact scan at that point.

* there are two kinds of stack frames: Ordinary methods generated by CodegenLIR, and invokers generated by InvokerCompiler.
* the front end knows the C++ type of each LIR_alloc'd (stack-allocated) structure, of which there are several, including MethodFrame, CallStackNode, and ExceptionFrame.  There are also ad-hoc parts of the frame, for example vars[], which contains local variables, and values passed as outgoing arguments to builtin helpers and AS3.
* In addition to explicit stack values, the backend will spill pointers at various places on the stack, and the frontend does not know where.  At the end of the assembly pass, any LIR instruction that was spilled will have a nonzero LIns.sharedFields.arIndex field, which indicates where the value was spilled relative to the frame pointer.  There is no record of the actual lifetime of the spilled value.
* the LIR type system consists of int, quad, and double, but not pointer, let alone three or four kinds of pointers.
* The SlotStorageType of each value in vars[] is kept in another stack allocated array called tags[], with one byte per entry.  If the contents of tags[] were valid at scan-points, a data driven scanner could use this info to scan the contents of vars[].  This might not be the best design; ordinarily few, if any, values in tags[] ever are read from, and dead-store-removal removes the stores.  

The JIT knows the type of each entry in vars[], and outgoing args, at each point in the method.  A particular slot in vars[] can change type at different points in the program.  Where "type" is one of { rcpointer, gcpointer, atom, or none }

Comment 2

[Lars T Hansen]

Data point.  With quasi-exact tracing 16 garbage collections occur during ESC compiling itself in batch mode (recompile all files).  These are the measured stack depths at the time of GC (Release_Debugger with memory profiling enabled):

*** STACK: 1684 bytes
*** STACK: 1236 bytes
*** STACK: 4468 bytes
*** STACK: 7908 bytes
*** STACK: 19012 bytes
*** STACK: 12548 bytes
*** STACK: 6148 bytes
*** STACK: 4404 bytes
*** STACK: 10548 bytes
*** STACK: 12436 bytes
*** STACK: 10740 bytes
*** STACK: 5412 bytes
*** STACK: 11028 bytes
*** STACK: 8052 bytes
*** STACK: 8916 bytes
*** STACK: 9668 bytes

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.