Mike Lambert (via RT) wrote: >> 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 ;). My favorit is prederef, ~1/3 less prederef ops due to equivalence of _ic and _i ops. >>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. I know of @ARGS and earlier problems. Fact is now (with patch) @ARGS aka P0 gets not collected, as it was earlier. But I'll try GC_DEBUG it. (s. subject "GC collects argv aka P0" by $me) What buffers/PMCs are concerned too? But anyway there seems to be a deeper problem related to unmanged buffers/PMC in early startup of interpreter. IMHO the init's in make_interpreter could be reordered to get this right. > 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? Yep, I don't know why this jump table uses system stack, it's static, nor why the observed size doesn't match the number of ops - gcc people might know it. I thought on dynamically allocating the jump table too, but info gcc states, that these labels are treated like constants, so I don't see a chance for a better solution. > Mike Lambert leo PS, sorry for broken quotings, old Mozilla ..
