At 2:01 PM +0200 10/2/02, Leopold Toetsch wrote:
>As already posted I incorparated the allocator from
>http://gee.cs.oswego.edu/dl/html/malloc.html
>in parrot.
>
>Some remarks:
>- it's totally stable now, runs all tests (parrot and perl6)
>- memory consumption is like CVS or much less ...
>- ... if resources.c is unpatched (#17702)
>- runs almost[1] everything in almost the same time
The license is fine for this, I'm not particularly wedded to any
memory allocator, and I think we might have sufficient restrictions
in place to make this feasable as a memory allocator.
Since all pool memory has to be anchored with buffers, and allocation
has to use buffers, the GC issues get subsumed into DOD runs, which
is OK--memory allocation, reallocation, and freeing will all be
actively traceable so we shouldn't leak, at least if we don't leak
buffers.
Could you, if you're feeling adventurous, rework resources.c and
memory.c to allow either the current scheme or the lea allocator? A
parrot compile-time switch is sufficient. (I realize much of the GC
system will just go away, and the DOD bits will be a little different)
It's work we should do anyway, as we're going to have to deal with
external allocators for embedded work, and if we work properly for
lea, we should work properly for that as well.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
