Re: [DRLVM] one more gc

2006-06-13 Thread Ivan Volosyuk
Weldon, Thank you, for your interest. The main idea of the implementation is just education of myself. I wanted to start with train algorithm to better understand its pros and cons. I didn't supposed to stick with that algorithm. Moreover, when just starting the implementation I noticed some

Re: [DRLVM] one more gc

2006-06-13 Thread Rana Dasgupta
Hi Ivan, On 6/13/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Btw, I have found small performance improvement to GCv4 which can be easily added to it. Could you please post more details about this possible perf enhancement to V4? ... Well, I'm going to do this development just for

Re: [DRLVM] one more gc

2006-06-13 Thread Rana Dasgupta
Ivan, Even if the vtable gc data layout change is small and code specific, it will be interesting to see the change proposal here first, specially if you are considering submitting it. Sounds quite promising. 1.5% is not small. Some details of which workload saw the 1.5% collection delta would

Re: [DRLVM] one more gc

2006-06-12 Thread Weldon Washburn
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

[DRLVM] one more gc

2006-06-09 Thread Ivan Volosyuk
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