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. 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. > > > If your buffer header can't be reached from the root set, you'll end > > up having it reclaimed when a sweep is made. > > Which bits of a PMC count as being reachable from the root set? Everything in any stack (including register stacks) plus PMCs shared between threads and finally those memory chunks explicitly registered as foreign (e.g. a manually administered reference).
