[ruby-core:20931] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use

Roger,

I see what you mean.  If these patches let the GC collect 
objects more efficiently, the object free list will not empty as often.
The speed up we observe for large single threaded apps could well be a
combination
faster ObjectSpace traversal and fewer GC passes triggered by an empty free
list.

My bogus2 benchmark switches between one thread having a very deep stack and
another with a shallow stack.  It's the worst conceivable case of stack
thrashing.  It runs about 15% faster if I disable only the clearing of the
stack.

I've spent a couple hours today "imagining" what might happen if each
thread's stack were cleared only once soon after each GC is run.  Here are
my observations thus far:

1)  I think I now see your point about VALUE pointers not necessarily
needing to be zeroed.
We just want to minimize the number of permanent ghost object pointers
residing on any stack.
When whatever transient ghost references remain, change value, GC will
eventually collect the objects to which they referred.  Correct?

2)  GC is not triggered by any thread's particular activities.  It may be
that a given thread, whose stack has become full of ghost references due to
deferred stack clearing, stops running for long periods of time.  Or, that a
such a thread just never happens to be running when a GC is triggered.

3)  It is critical that the stack be cleared very soon after each context
swap, when the new thread's stack is shallower than the old one's. 
Otherwise, VALUE pointers on the old thread's stack will likely be
incorporated into the new thread's stack when it grows (as ghosts there)
after the next context switch.

4)  More generally, there is no guarantee that any thread's stack, once it
incorporates ghost values during growth, will ever shrink later to allow
those values to be cleared off.

To me, this all adds up to requiring repeated clearing of the stack. 
Because, once ghosts have been pushed onto a thread's stack, they may just
stay trapped there indefinitely.
Could you formulate some pseudo-code of an algorithm you think would (almost
always) prevent the incorporation of ghost references without repeated stack
clearing?

I really want to believe :-)

- brent


-- 
View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bug--744--memory-leak-in-callcc--tp20447794p21190790.html
Sent from the ruby-core mailing list archive at Nabble.com.