> Now, trace_system_stack walks a ~1300 entries deeper stack in CGoto > run mode, because of the jump table in cg_core. Don't ask me about this > difference to 900 ops, gdb says so.
Ahh, good observation. (I'm more of a non-cgoto person myself ;). > Attached patch now sets interpreter->lo_var_ptr beyond this jump table, > reducing the time of trace_system_stack to 0.04s for above case. Unfortunately, this doesn't work too well as a solution. There are a few pmcs and buffers that appear before the call to runops. These must be traced by trace_system_stack or else get prematurely freed (think ARGV, pbc filename, etc). Try running with GC_DEBUG to see this happen. What I don't understand, however.....the ops_addr jump table appears to be a static variable. Shouldn't the contents of this static variable not be stored on the stack? Alternately, is it possible to allocate this jump table in the system heap (malloc et al), and store only a pointer to it on the stack? Mike Lambert
