help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] GC Crash/Bug due recursion?


From: Gwenael Casaccio
Subject: Re: [Help-smalltalk] GC Crash/Bug due recursion?
Date: Mon, 04 Jul 2011 12:48:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 06/27/2011 02:56 PM, Paolo Bonzini wrote:
On 06/21/2011 12:00 AM, Gwenael Casaccio wrote:

This bench stresses well the it. mark patch and crashes the rec. mark.
But I guess there are still bugs with contexts (I should take a look),
there is a strange crash (DNU with #printNl lookup symbol is not found
but it's present...). But that's a good start :-)

It's possible instead of the iterative version to use a mark with a
pointer reversal but it's harder to debug, requires high time-cost:
visits each branch-node at least (n+1) times, each visit requires
additional memory fetches, and each visit cycles 4 values +
reading/writing mark-flags.

Another solution is to use a stack guard (v8 does it) and checks
overflow Knuth propose something similar

Modulo the usual comments about irrelevant hunks :) it looks good,
thanks! Can you however ensure the invariant that the queue is empty
upon entry to _gst_mark, by making it accept an OOP? I believe this
simplifies the code and lets you add back the tail recursion
optimization you removed.

And it would be even better if you could keep the distinction between
marking one OOP and marking a range, because it removes a lot of traffic
to/from the mark queue (a bit cheaper than the stack because of no stack
frame overhead, but still expensive cache-wise). Which in turn means,
keep the API as is! :)

Anyway, good start!

Paolo

Is it better Paolo ?

Cheers,
Gwen

Btw
Thanks for all the time you spend for the review :)

Attachment: mark.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]