Java: Performance review

Java theory and practice: Urban performance legends, revisited [IBM Developer works]

A very well-written article that examines the popular belief on memory-allocation in managed object-oriented languages is inefficient.

From the article:
Brian Goetz has been a professional software developer for over 18 years. He is a Principal Consultant at Quiotix, a software development and consulting firm located in Los Altos, California, and he serves on several JCP Expert Groups. See Brian’s published and upcoming articles in popular industry publications.

Related links:

Advertisements

One Comment on “Java: Performance review”

  1. Hi Santosh,

    In my personal experience with running large enterprise class applications, I have had not much issues with the GC chewing up the CPU, or generating latency. That may be because I have bigger bottlnecks than the GC… so the affect of it all is not really noticeable.

    From the article:

    “While HotSpot offers a choice of three young-generation collectors (serial copying, parallel copying, and parallel scavenge), they are all forms of “copying” collectors and have several important characteristics in common. A copying collector divides the memory space in half and only uses one half at a time. Initially, the half that is in use forms one big block of available memory; the allocator satisfies allocation requests by returning the first N bytes of the portion that is not in use, moving a pointer that separates the “used” part from the “free” part, as shown by the pseudocode in Listing 1. When the half in use fills up, the garbage collector copies all the live objects (those that are not garbage) to the bottom of the other half (compacting the heap), and starts allocating from the other half instead. ”

    I feel in your case, it is this which is causing things to slow down….. so there is some fundamental issue that needs to be resolved.