On Thursday 04 April 2002 16:30, Michel J Lambert wrote: > > 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. :)
Say no more... ;-) > > > 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? What do you mean by "we"? :-) I don't consider register and stack allocation to be something external - they're there for the interpreter itself to do with what it sees fit, and therefore the mem*alloc functions are just fine. Now, something *other* than the interpreter requesting memory for itself - some script requesting space for a new PMC, for example - that needs full tracking. > > > 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. I honestly don't know. In order to stay within (or resize) the allocated buffer, you either have to peek at the guts yourself, or pass them to something that will do it for you. The first is ugly, the second slow. If life was all strings, I'd say hide it, and we'd slap it in as part of Parrot's string libs. But I don't think we can abstract that far. -- Bryan C. Warnock [EMAIL PROTECTED]
