Re: LuaJIT roadmap 2008

[Stephen Kellett <lua@...>]

Mike Pall wrote:
> I'm sure you have your own share of experiences with this issue,
> too. Right now I have no complete plan to change or extend the
> debug API. Not even a complete requirements analysis. But I guess
> I'll be forced to dive into this topic sooner or later.

Indeed. We do our patching at runtime, often finding a known entry point 
then trying to find a suitable call inside a function (which may be 
inside another function, etc). Its very fragile and often breaks with a 
new release of the VM.

I agree that there almost certainly a whole load of issues w.r.t 
debugging/profiling. I'm just thinking ahead to when people are using 
the JIT and then they want to do debug/profile.

I don't know if you've looked at the .Net or Java (JVMTI rather than 
JVMDI/JVMPI) debug/profiling APIs. They allow quite a fine grain of 
control over what is/is not provided (user selects what they want at the 
start).

I'm guessing the instruction table is small, could you have the 
instruction table per-state? Maybe only copy per-state when modified, so 
you'd start with one shared table. Or does this fail because some people 
like to have millions of lua states available at once for use with 
coroutines?

I'm assuming that the hook won't be for detecting runaway scripts, but 
for debugging or profiling. In which case I'd expect the recording 
behave "as normal" even with the hook present, because the hook will 
always be present, so your "hot" paths should still be representative, 
of what the app is doing. However, I'm sure you are a better judge of 
that than I.

For the runaway script idea, I wonder if a single API could be added to 
Lua that would return the number of instructions executed by a given Lua 
State. Then people could just call the API (which I guess would just 
return an integer) and the caller could decide if too many lua 
instructions had executed and abort the runaway script. No need for 
setting a hook etc. Just a random thought. Is that too simple? have I 
missed something?

Or you do the reverse, a function to specify the max number of 
instructions expected to be executed by a Lua State. Some sort of error 
condition, exception thrown, or callback called if instruction count 
exceeded? Of course, this latter solution has a higher overhead and 
probably not what people want.

Just out of interest, which platform are you doing your LuaJIT 
development work on? Or are you developing and testing on multiple 
platforms?

Stephen