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

Reply via email to