PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, November 05, 2001 12:03 AM
Subject: Re: vmem memory manager
> On Sun, Nov 04, 2001 at 01:47:44PM -0500, Dan Sugalski wrote:
> > I've not made any promises as to what type of GC system we'll use. I'm
> > gearing things
On Sun, Nov 04, 2001 at 01:47:44PM -0500, Dan Sugalski wrote:
> I've not made any promises as to what type of GC system we'll use. I'm
> gearing things towards a copying collector, but I'm also trying to make
> sure we don't lock ourselves out of a generational scheme.
I'd really like to hear th
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 ev
>
> 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
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 re
> "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 in
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 con
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 --
> 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.
> S
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 would
10 matches
Mail list logo
