> The concern is that both functions are still using the same arenas, which > means the original problems still wouldn't be solved, and we'd still have to > do all the workarounds around them. ;-)
Yeah, but I can't go ahead changing this stuff, especially if all the code isn't converted over to using it yet. One working step at a time, says Refactoring Man. :) > IIUC, the mem*alloc routines are for internal use only - it's how Parrot > allocate huge chunks of memory from the system that it can then parcel out > as it sees fit. Nothing on top or outside of Parrot should be using them. > The Parrot*alloc functions provide memory allocation by the Parrot VM for > the programs running on Parrot - IOW, *all* requested VM memory must come > out of the arenas, which means it all needs to be tracked by Parrot for GC. What about register and regular stacks? They allocate bunches of stuff to push data onto, using mem_sys_allocate, and mem_sys_free. Is it okay to use the mem* functions when we *know* how to manage memory ourselves? I think it'd be a pain to force copying all this buffered data when they know how to manage it themselves. The GC, I thought, was more meant for PMCs and Strings, where Perl5 had used refcounts. Why use the overhead of a GC when we aren't going to require it's tracing and copy-collecting abilities? > I wish the allocation headers were a little more invisible to things outside > the memory manager, like with XStrings. But then again, all these levels of > indirection confuses me to no end as to what's inside and what's not. Yeah. Is there some reason *not* to make resources.h included only inlcuded in resources.c and interpreter.c? That would provide this hiding you are seeking, would it not? Of course, if we want stuff to use mem_sys_* functions, per the above paragraph, this isn't really an option. Mike Lambert
