[Sorry this has taken so long (as has the rest of my replies to the list).
Between work and the LL1 workshop it's been busy]
At 11:59 PM 11/12/2001 -0500, Michael L Maraist wrote:
1)
Are we allowing _any_ dynamic memory to be non-GC-managed?
Yes. We'll have the case where some memory must be
On Tue, Nov 13, 2001 at 06:05:51PM -0500, Michael L Maraist wrote:
treat them separately. We're already having to treat handles differently
than buffer-objects. I'm also wanting to segregate lists of leaf-buffers,
Ok here is a reference to the thread that mentioned copy-on-write for
Michael L Maraist wrote:
Are we allowing _any_ dynamic memory to be non-GC-managed?
Parrot must allow third party libraries to use the standard system
malloc/free. Playing linker games to hide malloc/free gets *really*
ugly.
Can we assume that a buffer object is ONLY accessible by a single
On Mon, Nov 12, 2001 at 11:59:08PM -0500, Michael L Maraist wrote:
2)
Can we assume that a buffer object is ONLY accessible by a single
reverse-path-to-PMC? PMC's or array-buffers can point to other PMC's, so
it's possible to have multiple paths from the root to an object, but I'm
On Tuesday 13 November 2001 12:05 pm, Ken Fox wrote:
Are _all_ handles (PMC's, Strings, or whatever) that serve as
root-set elements dynamically allocated?
Nope. Part of the root set includes auto C PMC handles used by
extensions. You also have to think about hardware registers too
if GC
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
On Tuesday 13 November 2001 01:20 pm, Jason Gloudon wrote:
On Mon, Nov 12, 2001 at 11:59:08PM -0500, Michael L Maraist wrote:
2)
Can we assume that a buffer object is ONLY accessible by a single
reverse-path-to-PMC? PMC's or array-buffers can point to other PMC's, so
it's possible to
On Tuesday 13 November 2001 03:57 pm, James Mastros wrote:
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
On Tue, Nov 13, 2001 at 06:14:30PM -0500, Michael L Maraist wrote:
Extending mem-mngr data-structures (like the linked-list) to the
definition of a PMC is what I'm worried about; not exposing a function to
say GC-me-more-often. (I appologize for the LISP mneumonic :)
Hm. I think that the
On Tuesday 13 November 2001 06:37 pm, James Mastros wrote:
On Tue, Nov 13, 2001 at 06:14:30PM -0500, Michael L Maraist wrote:
Extending mem-mngr data-structures (like the linked-list) to the
definition of a PMC is what I'm worried about; not exposing a function to
say GC-me-more-often. (I
Dan gave a list a bit ago about some minimal assumptions about how we'll deal
with memory. I've been researching various memory management techniques, and
I'm noticing that various optimizations can occur if certain assumptions are
made.. It's still early in the game, but I thought it might
11 matches
Mail list logo
