Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [RFC] GarbageBin  (Read 4632 times)
0 Members and 1 Guest are viewing this topic.
Offline Stuart Still

Senior Newbie

« Posted 2003-03-10 09:44:18 »

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 Smiley

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);

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;
                  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;
Offline Herkules

Senior Devvie

Friendly fire isn't friendly!

« Reply #1 - Posted 2003-03-10 10:12:25 »

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.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Stuart Still

Senior Newbie

« Reply #2 - Posted 2003-03-10 10:25:20 »

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?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »

Medals: 1146
Projects: 3
Exp: 20 years

Eh? Who? What? ... Me?

« Reply #3 - Posted 2003-03-10 10:37:11 »

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 Grin
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 Smiley

Offline coilcore

Senior Newbie

Java games rock!

« Reply #4 - Posted 2003-03-11 23:08:49 »

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.

Offline jbanes

JGO Coder

Projects: 1

"Java Games? Incredible! Mr. Incredible, that is!"

« Reply #5 - Posted 2003-03-23 18:38:45 »

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. Smiley

Java Game Console Project
Last Journal Entry: 12/17/04
Offline swpalmer

JGO Coder

Exp: 12 years

Where's the Kaboom?

« Reply #6 - Posted 2003-03-27 15:35:37 »

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"

Pages: [1]
  ignore  |  Print  

Riven (845 views)
2019-09-04 15:33:17

hadezbladez (5789 views)
2018-11-16 13:46:03

hadezbladez (2602 views)
2018-11-16 13:41:33

hadezbladez (6205 views)
2018-11-16 13:35:35

hadezbladez (1498 views)
2018-11-16 13:32:03

EgonOlsen (4733 views)
2018-06-10 19:43:48

EgonOlsen (5789 views)
2018-06-10 19:43:44

EgonOlsen (3275 views)
2018-06-10 19:43:20

DesertCoockie (4174 views)
2018-05-13 18:23:11

nelsongames (5500 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!