Peter Gibbs wrote:
> I am very much in agreement with this concept in principle. I would like you
> to consider adding a name/tag/id field to all pool headers, containing a
> short text description of the pool, for debugging purposes.
I don't have a problem with that. And yes, it'd definitely he
Mike Lambert wrote:
> At one point, we had a mem_alloc_aligned, which guaranteed the start of a
> block of memory given any pointer into the contents of the block. If we
> store a pointer to the pool at the beginning of each set of headers, then
> we navoid the need for a per-header pool pointer,
Mike Lambert wrote:
> I'm currently favoring allowing for header pools on a per-type basis, not
> just a per-size basis. This would give us a 'hash' pool. The pool
> structure would contain function pointers for collection and/or dod
> purposes. (stuff that would otherwise be in a PMC vtable.)
I
Mike Lambert wrote:
> One idea, which is most closely in line with the current semantics, is to
> add a pool pointer to every header. I've found a few times in the past
> where such a pointer would have come in handy. This would allow us to call
> the pool's mark() function, to handle stuff like
> Okay, I finally give. For purposes of liveness tracing and GC, we're
> going to unify PMCs and strings/buffers. This means we trace through
> strings and buffers if the flags are right, and we need to add a GC
> link pointer to strings/buffers. It'll make things a bit larger,
> which I don't lik
Okay, I finally give. For purposes of liveness tracing and GC, we're
going to unify PMCs and strings/buffers. This means we trace through
strings and buffers if the flags are right, and we need to add a GC
link pointer to strings/buffers. It'll make things a bit larger,
which I don't like, but
