Re: Stack performance issue

[Tom Hughes]

In message [EMAIL PROTECTED]
Melvin Smith [EMAIL PROTECTED] wrote:

 You might want to modify register stacks too. I currently have a
 band-aid on it that just doesn't free stack chunks which works in
 all but the weirdest cases.

I've done that now. I also just realised that the stacks are
allocating their chunks directly from the system, which presumably
means the GC won't pick them up so they need to be freed directly.

I've done that for the register stacks, and I'll do the same for the 
other stacks unless somebody spots a flaw in my logic and points out
that the GC will catch it...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu

Re: Stack performance issue

[mrjoltcola]

On 02 Jul 2002 16:35:02 +0100 Tom Hughes [EMAIL PROTECTED] wrote:
I've done that for the register stacks, and I'll do the same for the 
other stacks unless somebody spots a flaw in my logic and points out
that the GC will catch it...

No, your logic is correct, stacks are still
outside of the GC. I'm working on fixing
this so I can finish co-routines and continuations
correctly. Right now if you play around with
continuations you'll get leakage.

That is the reason I left stacks allocated
at their high water mark until we fix GCed
chunks.

Meant to finish it this weekend, but life has a
way of interrupting; I should be able to commit
it this week.

-Melvin

Re: Stack performance issue

[Dan Sugalski]

At 6:59 PM +0100 6/30/02, Tom Hughes wrote:
There is a performance issue in the stack code, which the attached
patch attempts to address.

[Snip]

Some figures from my test programs, running on a K6-200 linux box. The
test programs push and pop 65536 times with the first column being when
that loop doesn't cross a chunk boundary and the second being when it
does cross a chunk boundary:

   No overflow Overflow
   Integer stack, before patch  0.065505s 16.589480s
   Integer stack, after patch   0.062732s  0.068460s
   Generic stack, before patch  0.161202s  5.475367s
   Generic stack, after patch   0.166938s  0.168390s

Yowtch! Go for it, though please make some comments in the code to 
the effect that the pointer to the next (unused) chunk should be 
invalidated if things get marked COW.
-- 
 Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Stack performance issue

[Melvin Smith]

At 06:59 PM 6/30/2002 +0100, Tom Hughes wrote:
of the ARM procedure call standard. The solution there is to always
keep one chunk in reserve - when you move back out of a chunk you don't
free it. Instead you wait until you move back another chunk and then
free the chunk after the one that has just emptied.

You might want to modify register stacks too. I currently have a band-aid
on it that just doesn't free stack chunks which works in all but the weirdest
cases.

-Melvin