Hello C hackers,
I added some temporary debugging output to CallContext's mark VTABLE to see
what's happening in the GC when Rakudo runs. Look at src/gen/core.pir in the
Rakudo directory, and especially the first PIR function (it's _block67 for me).
This function has 1425 PMC registers and 76 STRING registers.
Other interesting functions:
105P/0S (!class_init_1134)
120P/0S (!class_init_722)
1448P/0S (-unknown-)
151P/0S (_block27227)
181P/0S (!class_init_1070)
187P/0S (!class_init_1449)
297P/0S (_block13)
301P/0S (_block16799)
324P/0S (_block14638)
395P/0S (_block13)
Several other functions have 60+ registers. While sometimes that's necessary,
even eyeball lifetime analysis of _block67 in particular reveals that Parrot
could get by with far, far fewer registers. Very few Rakudo calls use more
than a handful of S registers, if any.
I won't *guarantee* that there's a huge runtime speed improvement here (though
iterating over dozens of registers in mark won't be fast), but we could cut
runtime memory use significantly. As well, if Parrot could reuse registers
after lifetime analysis proved that their contents were unused, we might be
able to collect more garbage--especially of locally created GCables which
won't escape the function.
I'm not sure we can save the register allocator in IMCC, nor should we.
We may be able to add a register allocation step to POST.
Ideas?
-- c
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
