[PATCH] PPC JIT failure for t/pmc/threads_8.pasm

[Jeff Clites]

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

[Leopold Toetsch]

Jeff Clites <jcl...@mac.com> wrote:
> 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.

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

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

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.

> ... it's hard to

> say what number is guaranteed to be large enough.

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

Thanks, applied.

> JEff

leo