Just In Time

Like my last post about threads and mush, this is a wild and crazy idea. Unlike the last one, I actually want to try this one out:

Use GNU Lightning to, on supported architectures, compile @lock bytecode to native binary code (When a lock is first tested; that's the JIT part).

Lock bytecode is a series of instructions, where each instruction is an opcode and an integer argument (Not always used, but if all instructions are the same size, life is easier.) Opcodes are dispatched via a switch; each opcode is one case. The compiler hopefully implements this switch as a jump table where the proper case is immediately executed after a single lookup to the find its starting address, but it can be a series of comparisons and jumps, depending on compiler, architecture and optimization options (gcc 4.1 using -O -march=athlon64 creates a table.)

Using @lock foo=$#1 as an example, the bytecode looks like:

T_OWNER #1
RET

And the evaluation to see if object what passes the lock goes something like this pseudocode high-level assembly (Assuming a jump table):

/* Setup code */
bytecode[] = { { op = T_OWNER; arg = 1; }, { op = RET; arg = 0; } };
jumps[] = { &T_CARRY, ..., &T_OWNER, &T_RET };
counter = 0;
/* Main loop of eval function */
goto jumps[bytecode[counter].op];
T_CARRY:
...
and more lock keys
...
T_OWNER:
result = db[what].owner == bytecode[counter].arg;
goto jumps[bytecode[++counter].op];
RET:
return result;

Compiled to native binary:

return db[what].owner == 1;

Or, in a lower-level notation that's how a member of a structure is actually accessed:

object = db + what;
owner = object + offsetof(struct db, owner);
return what_owner == 1;

The more complex lock keys like eval and flag are more difficult to implement, but it's still quite doable.

Now to find the time...