 |
lua-l archive |
|
|
||
|
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