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: Paolo Bonzini
Subject: Re: [Help-smalltalk] GC Crash/Bug due recursion?
Date: Mon, 27 Jun 2011 14:56:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Mnenhy/0.8.3 Thunderbird/3.1.10

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



reply via email to

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