On Mon, May 20, 2002 at 10:53:46PM +0200, Peter Gibbs wrote:
> Steve Fink wrote:
> > Is there some way to make the default be that things will not get
> > moved around, and allow routines to volunteer to have their guts
> > scrambled if they know how to handle it?
>
> A few random thoughts re buffers that don't wander around on their own:
> Create a new memory pool for immobile buffers (yes, we have a use for that
> flag at last) - I don't think we need different resource pools
> Immobile memory pools would have a new type of compactor function, that
> would maintain a linked list of free space (I suspect this would require
> multiple passes)
> Allocation would occur using one of the old-fashioned algorithms like
> first-fit
> This scheme may use more memory than copy-collection, due to fragmentation,
> and would obviously be slower for memory allocation, since it has to
> traverse a list of free blocks. In effect, it would be equivalent to using
> the operating system's memory allocation routine, except that we still
> retain GC control over it.
> However, being more expensive than the current Parrot allocation scheme may
> still be cheaper than a different homegrown solution every time somebody
> needs a buffer to stay put - the idea would be to use immobile buffers only
> when no more elegant solution is available for a specific problem, rather
> than have them as the default - most buffers should not be location
> sensitive?
>
> Alternatively, we say that buffers are, by definition, not location
> sensitive. Then we force the use of PMCs in those situations, and
> re-implement the original concept of telling a PMC to move its data to a new
> location. That would require scanning PMCs during memory pool compaction -
> at which point we are pretty close to unification of buffers and PMCs
> anyway??
>
> Comments?
Whenever I think about things from the garbage collector's point of
view, I think "what's the big deal? Things should be able to handle
being moved around." Then I think about it from the perspective of
some nontrivial data structure, possibly occasionally shared with some
external code, and think "why can't the garbage collector keep its
hands off while I'm in the middle of my code? Why can't I tell it to
leave me alone until I'm done?"
Other than proving that I'm an idiot with a split personality
syndrome, this suggests different levels of useful guarantees from the
memory subsystem:
(a) This memory will never move.
(b) This memory will never move between ops.
(c) This memory will not move while you're am processing. Tell me when
I can move it again.
(d) If you call anything outside your module, I can move stuff around
whenever I want.
(a) is necessary for things that are shared with external components.
(d) minimizes the probability of running out of memory because there's
too much garbage floating around. (b) and (c) are uncomfortable middle
grounds -- when you don't need memory, they're great, but when you're
running low then there's a good chance that some called routine will
exhaust what's available.
But it also seems that the annoying behavior is when some seemingly
unrelated object triggers the collection. For example, the hashtable
code wants the buckets to stay put while it's working with them. But
they get moved around as a result of string manipulations. If strings
running out of memory couldn't cause hash buckets to move, life would
be much nicer.
