[RFC] GarbageBin

[Stuart Still]

In an attempt to better control the collection of garbage, I decided it is (I think) advantageous to not nullify objects.  Instead, it makes sense to pass them to an 'storage' class that can be easily emptied and the System.gc() called.  This should limit (I think) the volume of work the garbage collector has to do, and allows you to collect garbage when it suits you, (i.e. between levels or whatever).  I don't know if the code is anygood, just wondering if anyone could comment on its usefulness.  Ohh, and if it is useful, feel free to use it

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47

/* GarbageBin is designed for situations where generating garbage will affect the performance of the program.  It prevents garbage collection by maintaining references to Object's until the programmer emptys the bin by nullifying all references and calling the garbage collector using System.gc() Usage Example:       GarbageBin bin = new GarbageBin(20);       String forBinning = "This string should be binned";       forBinning = bin.add(forBinning);       ...       bin.empty(); */ public class GarbageBin {             // The bin is simply an array of object refrences      private Object[] theBin;             // We need to know how many items of garbage are in the bin      private int garbageItems;             // Create a new bin to throw garbage in      public GarbageBin() { this(15);}       public GarbageBin(int size) {             theBin = new Object[size];             garbageItems = 0;       }             // Adds garbage to the bin.  If the bin is full, what should I do???      public Object add(Object garbage) {             if (garbageItems < theBin.length)                   theBin[garbageItems] = garbage;             else                   return garbage; // ATM just return the object to itself?            return null;       }             // Empty the bin      public void empty() {             for (int i = 0; i < garbageItems; i++)                   theBin[i] = null;             System.gc();       } }

[Herkules]

Now you have 2 big objects in your bin and force the GC to run 100x a second just because it cannot free memory? I feel it is not a good idea to claim for memory that is no longer used.

[Stuart Still]

Does that mean, that the less memory available the more the GC runs.  For example, if 32k is being occupied with objects, the GC runs half as many times as it would if 64K were being taken up?  Does this mean it is best to handle garbage as a normal application, but force GC to run when convient as well?

Stu

Games published by our own members! Check 'em out!

[princec]

The GC will kick in more often when memory gets tight. The precise way it does it is governed by some nonstandard tuning options.

What would be best for GC in games, in order of preference, is:

1. Don't create any objects
2. Stack allocation of objects, coming soon to a JVM near you
3. Incremental & concurrent collection
4. Time-limited running (limit to 1ms, for example)
5. Synchronized running with vertical blanking interval

Everything else about the Java GC is perfect. All that Reference stuff is probably way more complex than is needed for a game though and could easily be left out of a game-specific JVM.

Cas

[coilcore]

Theres a number of potential problems with this.

1.  This can shortcircuit many of the generational logic used in modern garbage collectors and force many objects into old generation when they should have been immediately discarded.

2.  Since you do not know the size of the object being added you cannot be sure that you will not run out of memory by perserving old data.

3.  You have a potential to make have invisible circullar references that can make for something that resembles a memory leak.

Some of these issues might be resolved by using SoftReference instead of the implicit strong reference (so that that GC can clean this stuff in a pinch), but still using incremental or concurrent GC is pretty good and should not cause significant problems these days.

[jbanes]

Hi stustill,

While coilcore is generally correct about shortcircuting the garabage collector, I did find a good use for this sort of thing. As you know, you try to keep zero object creation in your main loop when writing a game. However, I've found that object collection from items like enemies dying can extend the GC long enough to cause a pause. My solution was a garbage can similar to yours. Since no new memory is being allocated, the GC doesn't care if I hold onto it, and my game stays silky smooth. The one problem of course, is that you need to remember to empty the bin between levels or you *will* cause a problem. A couple of things I did different:

• I used an ArrayList with a suitable initial size (256 in this case). This means that a full bin doesn't result in errors.
  
• All the methods in mine are static. Since there's really no need to keep more than one bin around (more memory allocation), I went ahead and made only one bin for all code.
  
• I used the method name "pitch" instead of "add". Made it feel more like a real garbage can.
  

[swpalmer]

Just thought I would point out what most probably already know...
A circular reference does not create a memory leak with most Java VMs.
Objects are not collected based on reference counting.  They are collected based on "reachability"