Mike Lambert wrote:
>>And additionally, for + 10 % more generations in life.pasm
>>- tossed one instruction in the fast path of Buffer_headers
>>
>
> I don't believe this is valid. bufstart needs to be set to 0 when you free
> an object.
If I interprete the following code correctly (and what
> And additionally, for + 10 % more generations in life.pasm
> - tossed one instruction in the fast path of Buffer_headers
I don't believe this is valid. bufstart needs to be set to 0 when you free
an object. When the stackwalk runs, it could "liven" a dead buffer. When
the copying collector runs
Dan Sugalski wrote:
> I've committed this.
Thanks you.
> ...It fails two of intlist.t's tests, but only with
> the new allocator, so there's code in for folks to poke at and abuse.
Actually intlist's intlist_extend is wrong as the attached tests shows.
(If then there are still failures, w
At 6:51 AM + 10/3/02, Leopold Toetsch (via RT) wrote:
># New Ticket Created by Leopold Toetsch
># Please include the string: [perl #17731]
># in the subject line of all future correspondence about this issue.
># http://rt.perl.org/rt2/Ticket/Display.html?id=17731 >
>
>
>As adviced by Dan, th
Andy Dougherty wrote:
> Similarly, trying out perl5's malloc (the Kingsley malloc, very heavily
> modified by Ilya Z to better match perl's typical allocation patterns, and
> quite tunable) might be a good idea.
Brr, ugly code, deeply nested with per5-ismen ;-) ... But good idea ...
An hour l
On Thu, 3 Oct 2002, Leopold Toetsch wrote:
> [1] a test looks for availability of mallinfo, and assumes then, that
> the underlying libc uses ptmalloc (which is derived from Lea malloc
> 2.6.4). For this case, no malloc.c is linked to parrot, saving ~80 KB.
> (This test could be omitted, to use
e,
and commit them too - thanks.
http://gee.cs.oswego.edu/dl/html/malloc.html
Some TODOS:
- general doc of memory internals including DOD, GC and allocators
- integrate statistics and - if possbile - make the numbers (especially
allocated memory) comparable. mallinfo().uordblks is the whole memory
used, interprete
At 08:12 PM 12/12/2001 -0500, [EMAIL PROTECTED] wrote:
>Dan wrote:
> >># In lieu of a de-allocator for mem_allocate_aligned I vote
> >># we at least do something in the interim and I volunteer to
> >># help as soon as someone decides what it is!
> >>
> >>Maybe we can have a mem_free_aligned that s
Dan wrote:
>># In lieu of a de-allocator for mem_allocate_aligned I vote
>># we at least do something in the interim and I volunteer to
>># help as soon as someone decides what it is!
>>
>>Maybe we can have a mem_free_aligned that somehow figures out what the
>>starting address is. If we do that a
At 04:29 PM 12/12/2001 -0800, Brent Dax wrote:
>[EMAIL PROTECTED]:
># In lieu of a de-allocator for mem_allocate_aligned I vote
># we at least do something in the interim and I volunteer to
># help as soon as someone decides what it is!
>
>Maybe we can have a mem_free_aligned that somehow figures
At 05:20 PM 12/12/2001 -0500, [EMAIL PROTECTED] wrote:
> >The only thing that needs the allocated alignment is some of the internal
> >pieces--the stack chunks and register frames, really. Everything else can
> >use a plain malloc. Well, mem_allocate, rather, which can be a wrapper
>around malloc
[EMAIL PROTECTED]:
# In lieu of a de-allocator for mem_allocate_aligned I vote
# we at least do something in the interim and I volunteer to
# help as soon as someone decides what it is!
Maybe we can have a mem_free_aligned that somehow figures out what the
starting address is. If we do that and
>The only thing that needs the allocated alignment is some of the internal
>pieces--the stack chunks and register frames, really. Everything else can
>use a plain malloc. Well, mem_allocate, rather, which can be a wrapper
around malloc for now.
>
>Dan
Maybe we can do this for now?
-Melvin
---
At 05:04 PM 12/12/2001 -0500, [EMAIL PROTECTED] wrote:
>At minimum we should be using plain malloc() until a
>better solution or the current one is finished, else
>right now we have a glaring memory leak for ops that
>need to destroy strings.
>
>Can't the current function be at least tweaked so it
In lieu of a de-allocator for mem_allocate_aligned I vote
we at least do something in the interim and I volunteer to
help as soon as someone decides what it is!
I know GC is on the way but...
At minimum we should be using plain malloc() until a
better solution or the current one is finished, els
15 matches
Mail list logo
