Re: Minimizing Garbage collection in Latency sensitive applications

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®  http://www.develop.com

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