examples of garbage collection bottlenecks

Question

I remembered someone telling me one good one. But i cannot remember it. I spent the last 20mins with google trying to learn more.

What are examples of bad/not great code that causes a performance hit due to garbage collection ?

Answer 1

Your custom service does not have a load limiter on it, so:

• A lot requests come in for some reason at the same time (everyone logs on in the morning say)
• The service takes longer to process each requests as it now has 100s of threads (1 per request)
• Yet more part processed requests builds up due to the longer processing time.
• Each part processed request has created lots of objects that live until the end of processing that request.
• The garbage collector spends lots of time trying to free memory it, however it can’t due to the above.
• Yet more part processed requests builds up due to the longer processing time…. (including time in GC)

Answer 2

String foo = new String("a" + "b" + "c");

I understand Java is better about this now, but in the early days that would involve the creation and destruction of 3 or 4 string objects.

Answer 3

What are examples of bad/not great code that causes a performance hit due to garbage collection ?

The following will be inefficient when using a generational garbage collector:

1. Mutating references in the heap because write barriers are significantly more expensive than pointer writes. Consider replacing heap allocation and references with an array of value types and an integer index into the array, respectively.

2. Creating long-lived temporaries. When they survive the nursery generation they must be marked, copied and all pointers to them updated. If it is possible to coalesce updates in order to reuse of an old version of a collection, do so.

3. Complicated heap topologies. Again, consider replacing many references with indices.

4. Deep thread stacks. Try to keep stacks shallow to make it easier for the GC to collate the global roots.

However, I would not call these "bad" because there is nothing objectively wrong with them. They are only inefficient when used with this kind of garbage collector. With manual memory management, none of the issues arise (although many are replaced with equivalent issues, e.g. performance of malloc vs pool allocators). With other kinds of GC some of these issues disappear, e.g. some GCs don't have a write barrier, mark-region GCs should handle long-lived temporaries better, not all VMs need thread stacks.

Answer 4

One example would be object references that are kept in member variables oder static variables. Here is an example:

class Something {
  static HugeInstance instance = new HugeInstance();
}

The problem is the garbage collector has no way of knowing, when this instance is not needed anymore. So its usually better to keep things in local variables and have small functions.

Answer 5

from an old sun tech tip -- sometimes it helps to explicitly nullify references in order to make them eligible for garbage collection earlier:

public class Stack {
  private static final int MAXLEN = 10;
  private Object stk[] = new Object[MAXLEN];
  private int stkp = -1;

  public void push(Object p) {stk[++stkp] = p;}

  public Object pop() {return stk[stkp--];}
}

rewriting the pop method in this way helps ensure that garbage collection gets done in a timely fashion:

public Object pop() {
  Object p = stk[stkp];
  stk[stkp--] = null;
  return p;
}

Answer 6

I have encountered a nice example while doing some parallel cell based simulation in Python. Cells are initialized and sent to worker processes after pickling for running. If you have too many cells at any one time the master node runs out of ram. The trick is to make a limited number of cells pack them and send them off to cluster nodes before making some more, remember to set the objects already sent off to "None". This allows you to perform large simulations using the total RAM of the cluster in addition to the computing power.

The application here was cell based fire simulation, only the cells actively burning were kept as objects at any one time.