I was getting a failure under JIT on PPC for t/pmc/threads_8.pasm, and
the problem turned out to be that emitting a restart op takes 26
instructions, or 104 bytes, and we were hitting the grow-the-arena
logic just shy of what would have triggered a resize, then running off
the end.

The below patch fixes this; really that magic number (200, now) needs
to be bigger than the amount of space we'd ever need to emit the JIT
code for a single op (plus saving registers and such), but with the
possibility of dynamically loadable op libs (with JIT?), it's hard to
say what number is guaranteed to be large enough. Or, we can pick a
reasonable, largish number that works for the built-in ops (empirically
determined, as now), and document that loadable JITted ops which could
take more than this, need to make sure to grow the arena as necessary.
(And we could provide a utility function to make this easy.)

JEff

Index: src/jit.c
===================================================================
RCS file: /cvs/public/parrot/src/jit.c,v
retrieving revision 1.95
diff -u -b -r1.95 jit.c
--- src/jit.c   25 Oct 2004 10:24:14 -0000      1.95
+++ src/jit.c   29 Oct 2004 07:50:09 -0000
@@ -1395,7 +1395,7 @@
          while (cur_op <= cur_section->end) {
              /* Grow the arena early */
              if (jit_info->arena.size <
-                    (jit_info->arena.op_map[jit_info->op_i].offset +
100)) {
+                    (jit_info->arena.op_map[jit_info->op_i].offset +
200)) {
  #if REQUIRES_CONSTANT_POOL
                  Parrot_jit_extend_arena(jit_info);
  #else

Duh. It's probably time to generate a JITted restart function.

Not easily. Or it would be not too hard. Given a fairly complete
implementation of core.jit, we have a function table (per platform) that
has slots for every processor instruction (or almost: Parrot hasn't yet
vector opcodes). So a new opcode could be written in terms of existing
opcodes, which would easily allow the generation of JITted variants.

If a new opcode is too complex, it could be written (partly) in C, which
would need just one new JIT opcode call_c_func. And that is exactly what
Parrot_jit_build_call_func on i386 is already doing.

If we ever have loadable JIT code, will have an interface to set that
magic number.

Thanks, applied.

leo