Rakudo *Needs* Register Allocation

chromatic chromatic at wgz.org
Sun Jun 27 21:21:17 UTC 2010

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.


-- c

More information about the parrot-dev mailing list