On Feb 28, 2011, at 10:34 AM, Willem Rein Oudshoorn wrote:
Cyrus Harmon <firstname.lastname@example.org
I'm willing to believe
that we're leaking, but I don't think the thread_set_exception_ports
call below is the source of the leakage -- that's in mach_thread_init
which is only called once, IIRC.
Well, that call is called once per thread creation. So you can observe
the leak, and the effect of the leak by doing (while running top)
Ah, I forgot about the call in arch_os_thread_init. It's annoying that the code is organized differently for x86-64 and that the mach_thread_init call is actually in x86-64-bsd-os.c, but that's probably my fault.
After some small changes in the x86-64-darwin-os.c file the leak
(mostly) dissappears and the timings are:
23.510 seconds of real time
27.175448 seconds of total run time (8.769780 user, 18.405668 system)
[ Run times consist of 0.254 seconds GC time, and 26.922 seconds non-GC time. ]
50,811,597,876 processor cycles
94,373,984 bytes consed
23.433 seconds of real time
27.176067 seconds of total run time (8.775256 user, 18.400811 system)
[ Run times consist of 0.253 seconds GC time, and 26.924 seconds non-GC time. ]
50,643,689,122 processor cycles
94,372,736 bytes consed
I can send a patch (which is almost ready, I still want to look at the
remaining sporadic leak and I need to transfer the changes to the non 64
Presumably you took care of the leak in the thread destruction code as well?
However building and rebuilding takes a very long time. I do this by
But the only thing I change is the runtime. Is there a quicker way to
test sbcl with a rebuild runtime?
You can use :sb-after-xc-core and slam.sh, I think. There were some sporadic problems with this (it would be good to see if they still exist and track them down if so), but I haven't done this in a while.
Finally I have a question about the tests. In the testing directory
there are a few thread related tests which are not run on darwin
with scary sounding notes saying that they will crash or hang sbcl.
Is this old? Or is multi threaded sbcl not that stable yet on MacOSX?
Yes, these tests expose problems in multi-threaded SBCL (or the underlying OS). Fixing these would be greatly appreciated.
Thanks for getting the ball rolling here again.