Re: LuaJIT roadmap 2008

[Mike Pall <mikelu-0802@...>]

Stephen Kellett wrote:
> 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 guess these could be a model for an API, or at least a source
of ideas.

> 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?

It's ~320 bytes, i.e. too large. I'll have to think about the
copy-on-write idea though.

> 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?

IMHO most apps really want a hard timeout (e.g. run for max.
10ms). The instruction count is just a substitute since the Lua
core wants to remain clear of OS-specific stuff.

But LuaJIT isn't completely OS-agnostic, anyway. A timer-based
approach would be zero-cost. Converting this into a synchronous
callback is the only complication.

Similarly, breakpoints can be implemented much more efficiently
by temporarily patching the bytecode or the machine code.

My idea would be to build a high-level debug API directly into
LuaJIT and at the same time provide an add-on module for Lua
which simulates the functionality using the low-level debug API.
Maybe also a patch for the Lua core to add some extra hooks where
needed (e.g. catching all errors before they are thrown).

This would allow debuggers, profilers, sandboxes, signal handlers
(etc.) to be built upon a unified high-level API.

But that's just some random idea right now. I need to work on
other issues first.

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

Mainly Linux. Regular testing on other platforms with VMWare
Player and remote logins. Thankfully the x86 ABI is (almost) the
same on all platforms.

--Mike