harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [drlvm] what's next?
Date Mon, 26 Jun 2006 22:32:38 GMT
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.
Intel Middleware Products Division

On 6/20/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 6/20/06, Geir Magnusson Jr <geir@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message