Ivan, Please note that two guys who worked for me on ORP (http://orp.sourceforge.net/ ) spent 2-3 years building and tuning the train algorithm. We could never get the performance to acceptable level. Ultimately we ditched the train algorithm and built GCV4 in less than 3 months. GCV4 was never finished. I suspect other VM builders also experimented with the train algorithm and abandoned it. As far as I know, there are no production or research MRTEs containing the train algorithm. Also note there is already a complete implementation of the train algorithm in Apache compatible licensed open source. Look for orp-1.0.10.tgz on http://sourceforge.net/projects/orp ). The train algorithm is contained in the directory gc_v2. Since the GC/VM interface has not evolved much in the transition from ORP to DRLVM, it should be an easy port. This port would be interesting for two reasons:
a) A teaching tool to show why/where the train algorithm fails. Tony Printezis and Richard Jones wrote an excellent paper that used GCspy to graphically demonstrate where the train algorithm falls down. Look for, "GCspy: An Adaptable Heap Visualization Framework" by Tony Printezis and Richard Jones, (http://www.cs.kent.ac.uk/pubs/2002/1426/index.html ). Also look for, (http://research.sun.com/projects/gcspy/printezis-garthwaite-ismm2002.pdf ), "Visualizing the Train Garbage Collector". It might be interesting to hook up GCV2 and GCspy to harmonydrlvm and reproduce this paper. This would calibrate GCspy for future harmonydrlvm work. b) GC_V2 really stressed the write barrier subsystem. (GCV2 does a substantial amount of object copying.) If GC_V2 can be ported quickly, it might be a good stepping stone to getting MMTk going. On 6/9/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
While some works going on to properly integrate DRLVM in harmony build system... I would like to start development of new garbage collector. I know about Weldon's work related to MMTk. I am not sure that it is the right way. Instead of doing GC based on java, I would concentrate on the one written in C. I think that the VM written in C (or C++ ) should have GC written the same way. I have some experience in garbage collectors (stop-the-world ones for now) and want to extend my knowledge in this area. That is one of the reasons I want to make the GC, but do not port the existing one. I hope I will eventually produce something which is better then existing implementations or at least a few new ideas. I would like to start implementing something similar to Train algorithm, then possibly modify it in direction to Garbage First collector. I want to create something with high performance and low pauses. At the beginning it will not even compile. I do not expect this to be interesting to anyone for some time, but as Geir always suggests I going to do this in public to avoid surprises. All required VM functionality (for GC written in C) is already in place. DRLVM's interfaces for GC is ok for me and should be quite portable. Write barriers implementation is already in place, suitable for C-based Gc: (Harmony-504 (me), Harmony-581 (Ming Wu)). As I don't have commiter account, I going to create one JIRA and start to fill it with patches. In the patches I will create directory enhanced/drlvm/trunk/vm/gcx and will start to fill it with stubs and implementation. I am going to do it mostly at spare time. I hope this doesn't bother anyone. :) -- Ivan Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
