On Tue, Nov 13, 2001 at 01:51:26PM -0500, Michael L Maraist wrote:
> The various texts I'm reading suggest that memory management should be a
> black-box module.
Naturaly. All texts will suggest that everything should be a black-box
module, it's where engineering has been going for the past N^5 years.
However, their probably right this time.
> Unfortunately, this would require hooks into the mem-mngr module, which
> violates it's black-box nature. Not to mention the points you make.
I don't really see this as ownerous fiddiling with the memory manager; we
want to have hooks in to modify the timing of the GC anyway. All we have to
do is wrap a refcount around them (and I'm not sure about that; can you
really be in more then one XS at once?) and call them in the approprate
places. That isn't fiddiling with the internals of the memory manager, it's
timing is defined to be an external (by us).
> the foreign access area, and thus it's contents are reclaimable. Only
> remaining problem is in how the handle was acquired (hense my original
> question), since the handle needs to be reclaimed somehow, since the
> following is possible:
>
> PMC* ptr = malloc(sizeof(PMC));
> ptr = malloc(sizeof(PMC)); // memory leak
I think we're going to have to require XS writers to have /some/ discipline.
Either by being able to register their PMC pointers (and thus not be able to
put them in sombody else's management, like having them in a user data
parameter), or by using our malloc_PMC / free_PMC code.
> Heck, I'm even thinking that there should be two forms of newPMC, one to be
> used within the root-set, and one used externally. newPMC, and newPMCR (for
> registered).
(Personaly, I'd name them newPMC and newPMCext, since R could be for Root or
Registered.)
> It's still too early to see what's a good direction.
I think when it's too early to see what a good direction is, and it's
possible, the correct answer is both directions.
> root-set for each thread isn't that large, then pauses won't be that great.
> The only problem with this approach is that I'd like to hide the "prev/next"
> pointers since they are part of the black-box, and not part of the utility of
> the handles. But this requires some uniformity on how handles are created
> (ergo always from the arena).
I think we can just declare like
struct PMC {
struct PMC *next, *prev; // GC stuff, don't touch!
}
and trust XS writers not to touch.
-=- James Mastros
