Comments on: Tamarin Tracing Internals V: Running Compiled Traces

By: unutulmaz

unutulmaz — Fri, 05 Mar 2010 01:48:31 +0000

On the issue of reentrancy and tracing. I can see how we
could pause/resume or halt a trace upon detecting reentrancy,
but it’s unclear to me how we can guarantee correctness when
tracing into a re-entrant call, if I understood you correctly.

By: dmandelin

dmandelin — Tue, 10 Jun 2008 20:17:48 +0000

So it sounds like even the limitations on tracing aren’t fundamental, but require increasingly hard engineering. Good to hear.

By: Edwin Smith

Edwin Smith — Tue, 10 Jun 2008 19:21:44 +0000

> Could you give an example of an effect native methods can have that break tracing?

Say the call stack is Forth -> Native C++ -> Forth

We dont have a way of inlining the native C++ code, which would be required if we want to continue tracing down into the callee Forth code.

If we could inline the native C++ code, the inlined code would construct the C++ stack frame, such that if a Forth side exit were taken by teh callee, you’d return to the interpter, which could “return” to the native C++, and eventually retrun back to the outer interpreter.

We haven’t attempted anything like that. The native C++ call is traced as a call rather than being inlined, which means the inner forth code would be interpreted even if the outer forth code was traced. (altho the inner forth code could start looping, and be independently traced). For simultaneous tracing to work, the Interpreter instance in AS3 would need to not be global but rather be stack allocated or at least one per C++ interpreter stack frame.

By: Edwin Smith

Edwin Smith — Tue, 03 Jun 2008 20:02:07 +0000

As you suspected, the reason LIR_loop updates the interp state is for recursion. If we detect recursion then you’ll be adding some amount to sp, rp, and f each time through the loop. Recursion also forms a loop when unwinding, subtracting from the pointers.

recursion is detected by isRecursive() in the trace code for ENTERABC and EXITABC; if we’re calling into or returning into a method that is already on the call stack, then we treat the ENTERABC or EXITABC as a backwards jump.

You might find it odd that SideExit has data to update the interpreter state, but the stores to the stacks are on the main trace. This is an arbitrary decision, which is worth revisiting at some point. We could store the interpState updates on the main trace too, and then SideExit would be just the target and other sundry items. Then, store removal and store sinking could enable those stores to move to the side exits the same way stack stores could be moved.

By: dmandelin

dmandelin — Fri, 30 May 2008 18:26:08 +0000

LIR_loop: What I didn’t understand is that if the jump to the header is a local jump, then I think the sp/rp have to have the same values as they did on entry, so no adjustment would be needed. And I haven’t seen adjustments yet in the debugging output for my trivial examples. Under what circumstances do they occur? Recursive calls? That’s another thing that I noticed in there but didn’t totally figure out.

Reentry: I think I get the gist of what you’re saying, but it feels like there is still a big gap in my understanding. Maybe I don’t know enough about what effect native methods can have on the state–I didn’t look into them too much. Could you give an example of an effect native methods can have that break tracing?

I think at the Tamarin summit you mentioned something along the lines of splitting the native method into 2 parts, a ES or Forth part and a native part, and then put the callback in the ES/Forth part. In principle this seems like a good solution, I guess the only question is what does it actually look like with the callbacks in question.

By: Rick Reitmaier

Rick Reitmaier — Fri, 30 May 2008 16:01:43 +0000

LIR_loop exits update the interpreter state because we don’t
have logic that hoists instructions out into a loop header.
So when the code jumps back to the top of the trace its
re-loading sp/rp etc, out of InterpState and thus we need
to keep this structure current.

By: Tom Reilly

Tom Reilly — Thu, 29 May 2008 14:42:20 +0000

Great posting! TT isn’t re-entrant b/c we haven’t implemented it. Ie, interpMethodEnv assumes its using the whole stack and bad things happen if interpMethodEnv is re-entered on the same thread. Initially we’ll probably just exit in process traces on re-entrance but traces recorded in the re-entrant call will work, we could do more but that would be a good start. We never plan to trace across re-entrant calls with unknown arbritrary C code between the exit of the VM and the next interpMethodEnv we can’t guarantee a coherent trace.
Philosophically re-entrance should be avoided for that reason but in practice it will be necessary for certain situations.

By: Boris

Boris — Thu, 29 May 2008 03:16:54 +0000

Hmm. Most of the commonly-used DOM methods can potentially reenter JS (e.g. via mutation events), though they usually do not. What does that mean in terms of tracing the calls into those methods?