Re: [perl #19332] [PATCH] mark PMCs w/o next_for_GC

[Dan Sugalski]

At 6:02 PM +0100 12/21/02, Leopold Toetsch wrote:

Dan Sugalski wrote:

From a reading of the code, this allocates memory within a function that's called during garbage collection. We can't do that.

This buffer could also be allocated, when more PMCs are alloced. The size if fix, i.e. the total amount of PMCs.
And the memory get directly malloced from system.

Which argues against having it in one piece, unfortunately, as then we have the occasional need for one huge-ish chunk of memory. Damn. I wanted chunks attached to the pools originally, but that made marking rather expensive, as we had to do wacky bitmasking on the PMC pointer to get to the right entry in the pool mark slot.

... If you want to have a separate pool, or set of pools, that's allocated out of the GC run functions that's fine, but no memory allocations while we're cleaning up.

I don't get that.

If we're doing a GC run, it's because we're out of something, potentially memory. The last thing we want to do is fail in the middle of something we can't recover from because we need more of the resource we just ran out of.

We really ought to use the memory wrapper functions in memory.c, rather than malloc/realloc/free (yes, I know, I've been bad that way too) since we may be running in an interpreter that's got memory allocation control in place, or is embedded such that it should use the embedder's memory allocator instead.

Basically the worst-case failure mode is worse, and less-recoverable. Yeah, I know the scheme you're putting in place is faster, but this is one of the few times that doesn't suffice. GC time is almost as restricted as interrupt time in terms of what we can do. (Somewhere in the mailing list archive is a discussion of this--we've been here before)

That's the reason for the pointer that's in the PMC structure now, and the reason that we don't trace strings. (Memory savings on the latter, preallocated space in the former)

My approach uses prealloced space, just not inside the PMC.

It's the potential large size (which is a new concern) and the allocation of memory at GC time that troubles me, though the latter can be done at other times.

If we can chunk the pool up somehow, that'd be good, though I know there's a speed penalty there.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk