Re: Minimizing Garbage collection in Latency sensitive applications

Yes tuning can give good results but is a lot of effort.  IIRC there's a
really useful tool on the Sun site somewhere for analysing the verbose gc
output.  Can't remember what it's called now.

Also came across this recently that looks interesting:
http://domino.research.ibm.com/comm/research_projects.nsf/pages/metronome.metronomegc.html

On 17/08/07, Jeff Kesselman <[email protected]> wrote:
>
> Dmitry Beransky wrote:
> > I came across this article the other day.  It might be a helpful start:
> >
> >
> https://mail.csatravelprotection.com/exchweb/bin/redir.asp?URL=http://blogs.sun.com/partnertech/entry/a_short_primer_to_java
> >
> > On 8/16/07, Rodrick Brown <[email protected]> wrote:
> >
> >> I would like to start a brain storming session on ways to minimize GC
> >> on latency sensitive multi-threaded  applications anyone care to share
> >> some tips/ideas?
> >>
> >>
> (1) Take a deep breath and relax.  Gsarbage collection is much miuch
> better these days then it used to be.  In many cases it won't be an
> issue, especially
> if you design your app with a few things in mind.
>
> (2) The SunVM is generational in nature.  It is very good at two
> things:  allocating and disposing of short lived objects, especially
> smaller ones where the allocation
> is all around the same size, and handling very long lived objects.
> Where you can get into trouble is medium life objects that are big
> enough and/or long lvied enough to escape the eden (also called the "new
> generation" but still get deallocated in the middle of latency sensitive
> code.
>
> (3) The SunVM is tunable.  Keep in mind that if latency is your issue
> ans you *are* creating gc pauses, it might actually help to cut down on
> things like the eden space and heap space to make the gcs happen more
> often.  This seems counter intuitive but a gc that happens more often
> does less work per gc and, therefor, has a smaller latency hit.
>
> (4) DONT PREMATURELY OPTIMIZE.  Its one thing to design with some
> performance patterns in mind, ist another to try to design perfectly
> performing code out the gate.  It wont perfectly perform, period.  If
> performance is critical to your app you'll want to use a good profiler
> to tune it.  It is good however to build performance regression tests as
> early as possible and run them often.
>
> As an example of a well designed memory usage pattern for the gc, you
> cna look at most games.  (Thats my space actually.)  There are generally
> three kinds of objects in a game:
> (1) Temporary objects.  Use d to hold and pass values during frame
> calculation.  These are fairly small and get created and destroyed very
> quickly.
> (2) Level objects.  Objects that describe a  level of the game.  These
> get allocated at the start of level play and dont get deallocated til
> the end.  A level change is a good place for a gc pause because things
> like loading the next levels graphics are pausing play anyway.
> (3) Infratructure objects.  Objects that make up the core of the game
> code.  These are allocated at the beginning and never deallocated during
> the life of the program.
>
> ===================================
> This list is hosted by DevelopMentor(r)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>



--
Regards,

Dave Wathen

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com