[Bug-openmcl] processes not gc'd?
erik at adaptations.com
Mon Mar 1 15:21:05 MST 2004
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
> 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.)
More information about the Bug-openmcl