Dan Sugalski wrote:
I doubt there'll be GC pluggbility. (Unless you consider Ripping out the
guts of resources.c and gc.c and replacing them pluggability... :) If it
works out that way, great, but I don't know that it's really something I'm
shooting for.
That problem doesn't bother me too
dan at his recent talk at boston.pm's tech meeting said he was leaning
towards a copying GC scheme. this would be the split ram in half design
and copy all objects to the other half at CG time. the old half is
reclaimed (not even reclaimed, just ignored!) in one big chunk.
This schemes
At 07:34 PM 11/4/2001 +0100, Benoit Cerrina wrote:
dan at his recent talk at boston.pm's tech meeting said he was leaning
towards a copying GC scheme. this would be the split ram in half design
and copy all objects to the other half at CG time. the old half is
reclaimed (not even
- Original Message -
From: James Mastros [EMAIL PROTECTED]
To: Dan Sugalski [EMAIL PROTECTED]
Cc: Benoit Cerrina [EMAIL PROTECTED]; Uri Guttman
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, November 05, 2001 12:03 AM
Subject: Re: vmem memory
My intial impression is that a page should be 1024 bytes (though I'm also
looking at 512 bytes to reduce the shotgun effect of 8-byte allocs).
I've actually found that q-caches were detramental to things like
conslidation, and the calling depth (overhead) of a worst-case allocation.
So I'm
On Thursday 01 November 2001 09:08 pm, Ken Fox wrote:
Michael L Maraist wrote:
[an incredible amount of detailed information that will
take me weeks to digest...]
This looks like a malloc/free style allocator. Since the whole
GC system for Parrot is on the table, you don't have to
MLM == Michael L Maraist [EMAIL PROTECTED] writes:
MLM As with the relationship to the GC, my vision was that the GC
MLM would free memory objects as it found them unused (mark/sweep or
MLM what-ever), which only hands the memory regions over to the
MLM deallocator, which intelligently
On Friday 02 November 2001 01:33 am, Uri Guttman wrote:
dan at his recent talk at boston.pm's tech meeting said he was leaning
towards a copying GC scheme. this would be the split ram in half design
and copy all objects to the other half at CG time. the old half is
reclaimed (not even
Michael L Maraist wrote:
[an incredible amount of detailed information that will
take me weeks to digest...]
This looks like a malloc/free style allocator. Since the whole
GC system for Parrot is on the table, you don't have to constrain
yourself to malloc/free. IMHO free is not needed at all
This references the previously posted (by someone else) article on SUN's libu
memory architecture. If needed I can run through the archives and find the
URL.
I've already written a threaded implementation which has a decent
responsiveness. It did as much as the SUN libu claimed that it
10 matches
Mail list logo
