Leopold Toetsch wrote: > Event handling currently works for all run cores[1] except JIT. > > The JIT core can't use the schemes described below, but we could: > 2) Patch the native opcodes at these places with e.g. int3 (SIG_TRAP, > debugger hook) cpu instruction and catch the trap. Running the event > handler (sub) from there should be safe, as we are in a > consistent state > in the "run loop".
I don't think that bytecode-modifying versions should fly; they're not threadsafe, and it would be nice to write-protect the instruction stream to avert that attack vector. > 1) explicitely insert checks, if events are to be handled > 1a) everywhere or > 1b) in places like described below under [1] c) I like this (1b). With the JIT, an event check could be inlined to 1 load and 1 conditional branch to the event dispatcher, yes? (So long as &interp is already in a register.) If that's done before blocking and at upward branches, the hit probably won't be killer for most of code. For REALLY tight loops (i.e., w/o branches or jumps, and w/ op count less than a particular threshold), maybe unroll the loop a few times and then still check on the upward branch. Those branches will almost always fall straight through, so while there will be load in the platform's branch prediction cache and a bit of bloat, there shouldn't be much overhead in terms of pipeline bubbles. The "event ready" word (in the interpreter, presumably) will stay in the L1 or L2 cache, avoiding stalls. No, it's not zero-overhead, but it's simple and easy enough to do portably. Crazy platform-specific zero-overhead schemes can come later as optimizations. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
