I would just like to add that's my main argument against a concurrent GC eg
Put the time in a VM ( which shouldn't be much) , better static memory management and a fast Nursery based Gen Mark/Sweep and you have an excellent initial solution. You can use the VM for most things and also static memory managed native code where needed and it's the same language. This would IMHO be less resources and simpler than say a pause-less GC and static memory management. This should IMHO be a phase 2 ( which you have already stated anyway ) . I also believe a initial VM will give - Good early performance while the compiled parts catch up and put a nice competitive performance score on the board. Competition is good J - Give a nice lib so you can write real world apps - Allow coding apps in VS ( yes I miss it Eclipse , KDE dev and Emacs don't do it for me so I use Kwrite) , maybe even debug. - A stronger market. - Compile and dev as a VM then compile native for final. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
