[gambit-list] Termite, IO and memory leakage
nwalton at mac.com
Tue Nov 25 07:55:21 EST 2008
I have a large Termite based system that runs over eight cores on OS X Leopard. The system distributes itself over as many Termite processes as are made available and each process may make use of anyother. However, I have been getting odd segmentation errors occurring.
I have shrunk the code down to the framework built on top of Termite and a small example (as below)
(define (stress-test n m)
(lambda(j) (+ j j)) ; (newline) (write j))
(make-integer-list (+ 1 i))
The interface to Termiote is through dpmap-split which acts as a distributed form of map by partitioning the calls from map over the slaved Termite instances, via remote-spawn.
Executing (stress-test 1000 0) termintates as expected. I have logging code in dpmap-split which writes to the terminal's for all the processes with no problem. However if I replace the (+ j j) call with (newline) (write j)) then after a while (stress-test 1000 0) fails with a segmentation violation, having until then written to each instance's terminal the values as I would expect. Termite appears to have a problem with IO within spawned processes.
Secondly, even with (+ j j) in place it gobbles up core as if there is no tommorrow. By the time (stress-test 10000 0) completes using three instances, each instance has nearly 1Gig allocated. This is causing me considerable problems with the development system that relies on Termite to support its computational requirements and runs for hours at a time making many hundreds of call to Termite via dpmap-split.
The interface dpmap-split is side effect free. I have patched Termite's make-tag function to return a string instead of an interned symbol, and traced string->symbol to ensure that interned symbols are not building garbage up, but still Termite devours huge amounts of core.
Any ideas please?
More information about the Gambit-list