Image Caching With JList

Question

Hi all, I need to know, how can I implement an Image Cache feature with a JList that is effective, ie. basic I would like the images to be stored in memory when the list is visible (done that already using a WeakHashMap<String, Icon>) and removed from memory when the JList is not displayed.
Currently I use the following code section, to try and remove the data from memory, seems not work according to task manager. Sorry I cannot seem to come up with a good SSCCE since I'm not exactly sure how to make an example that loads images. Any suggestion with that?
WeakHashMap<String,Icon> icons = new WeakHashMap<String,Icon>();
JList list = new JList(); // something like this in actual code
public void startClearTimer() {
    new javax.swing.Timer( 30000, new ActionListener() {
        public void actionPerformed(ActionEvent e) {
            if(!list.isShowing() && icons.size() > 0 ) {
                resetIconCache();
                System.out.println("Icons Cleared");
                System.gc();
                //((javax.swing.Timer)e.getSource()).stop();
    }).start();
public void resetIconCache() {
    if(icons == null) {
        return;
    Iterator<Icon> images = icons.values().iterator();
    while(images.hasNext()) {
        ImageIcon icon = (ImageIcon)images.next();
        icon.getImage().flush(); // smoke but no cigar
        icon = null;
    icons.clear();
    icons = new WeakHashMap<String,Icon>();
}This code is used in a ListCellRenderer, which loads the images, scales them, caches them in memory so the repaints are faster and displays them along side some JLabels.
So basically how can I load the images in memory and release the resources used when the images are not required?
ICE

Answer 1

you can't be cleverer than JVM for memory usage.
Of course you can, because the point of caching is that it requires (or at the very least is optimised by) some understanding of the use case. JVMs are somewhat unlikely to predict how any given set of users will use any given application, nor are they capable of factoring in the cost of downloading (or otherwise obtaining) data which has been freed from memory. To a JVM, a lump of voidable memory is no different to any other.
Take an example of an applet (which is limited to 96Mb of heap) which browses images on a server. Let's say it's looking at images which occupy 20Mb of memory each (far from unreasonable) in memory. They might each be 1Mb or so in compressed file size, which is an appreciable delay in download time.
Each time the user switches between images, the applet will probably want to implement a policy that says "that last image should be kept in memory if possible, since the user might return to it and they won't want another long delay to load it, but if you run out of memory downloading the next image, feel free to discard the first, because the next is more important." (Furthermore, your workflow might permit you to prioritise images.)
In order to indicate to the JVM that the first image is disposable, you must clear all strong references to it. However, this simply makes it eligible for garbage collection: simple as that. You have no control over whether the garbage collector will clean that image data (which takes several seconds to retrieve) or a bunch of other data which is completely useless or can be recreated in milliseconds. Also note that in practice, weak and soft references do not actually encourage the GC to retain the data: it is cleared long before the memory is actually required.
Note, too, that the suggestion of tweaking the heap allocation is no use for an applet (unless you have a very small, very knowledgeable and very tolerant user base).