Q:

Should (can?) I override the Robot class to save memory with repeated screen captures, or is the GC good enough?

EDIT #2 - I decided this may be over-optimization and will try to use the Robot class as is until I run into problems, but FWIW:
I'm designing an application (strictly for OSX Lion) that runs alongside some very CPU and memory intensive software, including audio software that shouldn't be halting it's operations due to short CPU spikes/overloads. Like most audio software, memory is constantly being read/written.
This is a very lightweight application - its main purpose is to take a few screen captures every minute over the course of up to a few hours, using the the createScreenCapture method of the Robot class.
Upon each subsequent screen capture, the previous one is not needed. After looking at the Robot source code, it appears that a new BufferedImage is created every time createScreenCapture() is called, which means that the previous one is left for garbage collection, correct?
I am new to Java and the garbage collector. I'm worried about the CPU spikes caused by the necessity of the GC to manage/delete these old captures. Ideally, the image could go directly from the screen to overwrite the same area in memory every time, and the memory footprint of the Application will stay fairly constant without the GC working too much.
Is it advisable/possible to try extending the Robot class and overriding createScreenCapture() so that it uses the same static BufferedImage? If this were to work, I can't see any advantage to anybody with the current way Robot allocates new memory for every capture.
Thanks.
EDIT #1 - the relevant Robot source code, taken from here, is below. It appears that not only is a new BufferedImage created every time, but also equally large int[], DataBufferInt, and WritableRaster. Plus whatever overhead is created by peer.getRGBPixels() - which seems to connect to the graphics driver, but I can't find any source or info on this. Am I wrong in thinking it is wasteful to not reuse the same memory? It's clear that using static pointers will not solve anything. The BufferedImage would need to be overwritten using its own set methods. I added my own comments on an approach for this, marked with $$$. Theoretically it would save lots of GC action for my application, but is this even worth worrying about? If I knew more about java and profiling, I would get right to trying it all out.
public synchronized BufferedImage createScreenCapture(Rectangle screenRect) {
    checkScreenCaptureAllowed();

    // according to the spec, screenRect is relative to robot's GD
    Rectangle translatedRect = new Rectangle(screenRect);
    translatedRect.translate(gdLoc.x, gdLoc.y);
    checkValidRect(translatedRect);

BufferedImage image;
DataBufferInt buffer;
WritableRaster raster;

if (screenCapCM == null) {
    /*
     * Fix for 4285201 
     * Create a DirectColorModel equivalent to the default RGB ColorModel,
     * except with no Alpha component.
     */

    screenCapCM = new DirectColorModel(24,
                     /* red mask */    0x00FF0000,
                     /* green mask */  0x0000FF00,
                     /* blue mask */   0x000000FF);
}

    // need to sync the toolkit prior to grabbing the pixels since in some
    // cases rendering to the screen may be delayed
    Toolkit.getDefaultToolkit().sync();

int pixels[]; //$$$ do away with this array altogether?
int[] bandmasks = new int[3];

pixels = peer.getRGBPixels(translatedRect); //$$$ not needed
buffer = new DataBufferInt(pixels, pixels.length); //$$$ not needed

bandmasks[0] = screenCapCM.getRedMask();
bandmasks[1] = screenCapCM.getGreenMask();
bandmasks[2] = screenCapCM.getBlueMask();

raster = Raster.createPackedRaster(buffer, translatedRect.width, translatedRect.height, translatedRect.width, bandmasks, null);
//$$$ not needed
//$$$ i don't know what bandmasks are, but maybe the full-size raster could be initialized once with the bandmasks array, then...
//$$$ ...use raster.setPixels(0, 0, translatedRect.width, translatedRect.height, peer.getRGBPixels(translatedRect));

image = new BufferedImage(screenCapCM, raster, false, null);
//$$$ instead use image.setData(raster);

CachingSurfaceManager.restoreLocalAcceleration(image);

return image;
}

A:

Don't be afraid of allocations and GC, they do a very very good job, so you don't need to worry about them. I can tell your solution will work because I've implemented a real-time screen capture with AWT Robots, one that was capturing the full screen 20 times per second! It could run for hours with the default JVM parameters -Xmx64 and without a single problem.

