If somebody interested, I can share my GC which was made to replace GC v4. It addresses performance issues I've noticed on GC v4: - too many atomic ops - too many bit shifts - too many passes (touches of objects data)
New GC (which has code name gc_yuk) is combination of copying and compacting collector with adaptive switching. It can switch from copying to compacting during one GC, so evacuation area can be quite small and dynamically predicted. Copying collector has very simple code pass with one advanced idea and it is extremely fast. Sliding compacting algorithm is used when performance equation suggests it or when evacuation area overflows. About performance, on SpecJBB2005 (modified to be used on jre1.4) on Dual HT Xeon 3.2GHz gc_yuk versus gc_v4 gives: - 27% score gain - 7 times less average GC pauses - 5 times less time spent in stop-the-world state I think the idea of all advanced algorithms is to give high performance, IMHO this code would be good starting point in performance race. I am going to continue improving and experimenting with this code base. The code is quite small ~170kb of sources with 1/3 of it in copyright headers. And quite clean and easy for experimenting. I have tried a few parallelization attempts, but it didn't give me performance improvement on the mentioned above server. Looks like the limiting factor of performance is memory speed - little CPU work needed, but all live objects need to be scanned. Next step would be to make a concurrent GC algorithm, it can be a solution for further performance improvement. -- Ivan Intel Middleware Products Division On 6/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 6/20/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > Build and dependency issues aside, what are the next functional > enhancements / features for DRLVM? > > I think #1 is to get it to function with Java 5 classfiles, so we can > make the switch throughout the project. > > Thoughts? What else? I agree with java 5 being #1. Some additional thoughts. GCV4 needs replacing for a variety of reasons. The port of MMTk should pick up a bunch of the great GC work being done in the Jikes/MMTk community. It would also be nice to have a simple C generational collector. I am real busy with MMTk port. Otherwise I would volunteer to look into porting SableVM's generational collector. I think it was written by Carl Lebsack. Porting both MMTk and SableVM GC would give DRLVM a much better basis for generic VM/GC interfaces. Another thing that needs to happen in DRLVM is a well designed VM-JIT-GC synchronization protocol. Clear, understandable system-wide synch protocol will be very nice to have when we get to the point of advanced threading module. This really does not exist today. If there is interest, I could start a harmony-dev email thread on this topic.
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
