At 11:38 AM -0500 2/15/02, Michael Maraist wrote:
>On Fri, 15 Feb 2002, Alex Gough wrote:
>
>> On Thu, 14 Feb 2002, Dan Sugalski wrote:
>>
>> > To allocate memory that is GCable, call Parrot_allocate(interpreter,
>> > size). Then stash the pointer and size in your buffer header, or
>> > it'll go missing later. To resize a chunk of memory, call
>> > mem_realloc(interpreter, from, oldsize, newsize).
>>
>> Having to pass in the oldsize makes it very tricky to use wrappers
>> around around mem_realloc which work when code isn't in parrot, is it
>> not possible to have the memory pools themselves be a bit more like
>> malloc/realloc in tracking allocated sizes (I imagine they need to do
>> this anyway, if GC is to free chunks appropriately)?
>
>While this is certainly possible, I believe the intent was to allow
>the Parrot core to have as much control and access to the data-set as
>possible.
Yep. The more sophisticated GC mechanisms require this if they're to
function at all well.
>Normally you'd have to use gc_mem_sizeof( ptr ) to get the
>size. This would encourage caching of the size value (possibly in the
>local structure.. By having the size shared by both the user-defined
>structure and the gc, you avoid both the function call and the wasted
>memory. This is just speculation on my part though.
I've got the buffer structure already defined. It's:
typedef struct {
void *bufstart;
UINTVAL buflen;
UINTVAL flags;
} Buffer;
and that'll be visible to user code, I think. It's the first part of
STRING structs, conveniently enough. (Fancy that... ;)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
