Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <pe...@jall.org>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Date: Sun, 4 Aug 2002 06:10:43 -0400 (EDT)
X-X-Sender: mo...@jall.org
To: Dan Sugalski <d...@sidhe.org>
Cc: perl6-intern...@perl.org
Subject: Re: Unifying PMCs and Buffers for GC
In-Reply-To: <Pine.LNX.4.44.0208040428160.1222-100000@jall.org>
Message-ID: <Pine.LNX.4.44.0208040605400.1260-100000@jall.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp.perl.org
From: pe...@jall.org (Mike Lambert)
References: <Pine.LNX.4.44.0208040428160.1222-100000@jall.org>
Lines: 27

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 pointing-to-buffers, etc.

Oh, I meant to mention an alternative to the pool pointer, but forgot...

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, at the cost of a bit
more math and an additional dereference to get at it.

The benefits to this are the drawbacks to the aforementioned approach, but
the drawbacks include:

- additional cpu, and/or cache misses in getting to the pool. for dod,
this might be very inefficient.

- it imposes additional memory requirements in order to align the block of
memory, and imposes a bit more in this 'header header' at the beginning of
the block of headers.

Mike Lambert