On Thu, 2007-08-16 at 15:03 +1000, skaller wrote:
> Felix gc is now reasonably efficient. However,the world-stop at
> service call constraint plus some continued inefficiencies in the
> optimisation process make some functional code impractical.
> Any suggestions on the way forward appreciated.. :)
This is still a major issue for me. In the gc test code,
my comp only just manages to run it with 1Gig Ram,
yet the test is only using a couple of maps and folds
to make a 64K element list.
If we actually used that technique to make fthreads,
we'd blow my box out of the water long before the
claimed 1 million thread "easily on an AMD64" was met.
Boehm-gc would not have this problem, however it is
also world stop I think.
I believe I could fairly easily make a conservative
scan of the current thread stack (just needs to find
the top and bottom of the stack), allowing collection
of a single thread anywhere/anytime....
....but this will NOT work with pthreads.
Without a write barrier, and a generational gc, I see no
solution here.
Garbage collection is an intrinsically wrong algorithm.
It has to scan EVERYTHING in a stable state to work.
Local management as in C++ is horrible to code.. but it scales.
I may need to look for temporary erasure solutions. For example,
seeing
map f (map ... )
the inner map is a temporary .. is can be erased without
bothering about garbage collection.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
