Another thing I'd like to do, is throw in is a randomizer, to change the way the allocator assigns registers. Considering all the cruft that was uncovered when the algorithm was changed, it might be a good idea to have a debug feature that selects registers differently each time it runs (each allocation should be valid, of course). This could help flesh out any other faulty assumptions in the parrot compiler.
That'd actually help quite a bit. I've run into a number of cases where things worked only through sheer happenstance -- subs that were used before they were actually fetched, but only because they'd been fetched before and the temp registers mapped the same. Being able to throw a random seed into the pir compiler'd be nice there to flush those out.
That's definitely not very efficient. Plus it's mallocing each Life_Range, which is usually at least another 8 bytes per chunk, and then a lot of potential thrashing when freed. It seems I've seen a lot of less than optimum code like this, and I suspect there's a lot more like it.
Yow. That'd also trigger pathologically degenerate code in some versions of glibc's memory deallocation system.
Solving these things will bring me that much closer to the ultimate goal of defeating Dan's evil code. ;)
Better save that code -- I'm working on some machine generated Anti-Evil(tm) for it. If I'm lucky I won't be able to recreate it without some CVS fiddling. :)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
