[Bug-openmcl] processes not gc'd?

[Erik Pearson]

Gary Byers wrote:
> 
> On Mon, 1 Mar 2004, Erik Pearson wrote:
> 
> 
>>And it looks like the changes are already making their way into cvs ...
>>will this be in bleeding edge? And you'll announce on bug-openmcl?
>>(Yeah, I've updated the latest from CVS and see that there is both work
>>being done, and some recovery of memory with (gc)).
>>
> 
> 
> One way to tell whether or not the thread cleanup code works (without
> using printf) is to count the Mach threads in the "task".

The number of tasks reported seems to always return to normal. I guess 
this is a sign that the clean code is indeed running -- if it is invoked 
at all. (If the callback was someone corrupted, tht would disable the 
cleanup, right?, but the thread would still exit.)

I had reported before that when run "slowly" threads were returning 
memory correctly. Perhaps I was premature. It looks like they continue 
to eat up memory about about 8K per thread after (tc).

Now, (room) reports a completely stable system, in terms of what it 
measures -- memory usage returns to exactly what it was before the 
threads ran. However top continues to show increased memory usage by the 
dppccl process, and the lisp process in general shows performance 
degredation as more threads are created and thrown away (the latter 
could be due solely to paging.)

So perhaps the "thread entanglement" is a red herring (due to funny 
fprintf interactions?) -- is it possible that some 8k of objects are not 
being properly deallocated or are lost in the area?

Is there some limit on the ability of the lisp to return memory to the 
system?

> 
> Since this is the World's Most Advanced Operating System, you have to
> allocate a "big enough" buffer before asking Mach to tell you the answer;
> this assumes that the answer is <= ~15K:
> 
> 
> (defun count-mach-threads ()
>   (rlet ((n :mach_msg_type_number_t 0))
>     (%stack-block ((buf (ash 60 10)))
>       (#_task_threads (#_mach_task_self) buf n)
>       (pref n :mach_msg_type_number_t))))
> 
> There should always be one additional thread (used in exception handling)
> beyond those that (ALL-PROCESSES) knows about, so calling COUNT-MACH-THREADS
> in a vanilla OpenMCL should return 3.  After running your thread-creation
> stress-test, the number of threads should return to 3; it may take a little
> time if there's contention.
> 
> I'm pretty confident of that code; I'm not yet convinced that the GC
> doesn't need to lock the all_areas list before accessing it.  (If there's
> a way to ensure that doubly-linked-list insertions/removals can happen
> atomically - by using interlocked loads and stores - that'd be even better.)
> 
> 
> 
>>Erik.