On Wednesday 03 April 2002 16:55, Michel J Lambert wrote: > > Why add new functions instead of patching the current ones? > > I didn't know if the original functions still had a purpose. Perhaps you > would want to Parrot_allocate for something non-bufferish? Thinking about > it, that seems evilly wrong, so I guess that is not a valid reason. Doing > this would make mem_realloc and Parrot_reallocate_buffer a little bit more > difficult, since they'd have to allocate a temporary buffer on the stack > to call the function, or stash away the values of the incoming buffer > before it gets overwritten, so it can later memcpy. > > Should I resubmit a patch removing the _buffer suffix, and removing > mem_realloc?
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. ;-) 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. 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. -- Bryan C. Warnock [EMAIL PROTECTED]
