Question

I have following function which is called continuously from run() of a Thread which is continuously running.

private LinkedList<short[]> playerData = new LinkedList<short[]>();

public synchronized void setPlayerData(short[] buffer) {
        // Log.i(LOG_TAG, "Inside setData..");
        playerData.addLast(buffer);
        if (playerData.size() > 10) {
            // Log.i(LOG_TAG, "playerData not empty");
            playerData.removeFirst();
        }
    }

Now allocation Tracker of DDMS says that a lot of objects are created inside addLast() (actually inside addLastImpl() ), So for that I would like to delete the arrays explicitly so that their is always enough memory in Heap. Now,

1. System.gc() option won’t help because it will be called concurrently on every call to setPlayerData().
2. GC_CONCURRENT is eating all the CPU cycles, since app is very sensitive for time and even a few mili second delay is not acceptable.

For LogCat information please see the link, which is my another question addressing the whole synarion. In this thread I am just trying to solve that bigger problem by dividing it in set of small problems.

A possible solution A possible solution could be to free the memory space explicity by deleting the arrays which are not required. But in Java how can we free an array created by the new operator ? i.e.

short[] buffer = new short[320];
// do some operation on buffer
/// now how can I explicitly free memory by deleting the buffer, when its job is over..

I know there is garbage collection to take care of all such things. But in my app GC_CONCURRENT eats up all the time. Other processes are starved due to this. It would have been great if I am able to explicitly free memory, i.e. delete in C++. You can see the LogCat information here…A detailed question regarding my problem

EDIT 2
3. Assign arrays to null

How that will help ? null arrays will be scheduled to Garbage Collection which I want to avoid since the method is called from a thread continuously (in every 20 ms). If I assign the array to null, GC_FOR_MALLOC messages will fill the LogCat…

Answer 1

Your problem won’t be solved by explicitly deleting objects … basically because there is no way to do that in Java.

If you are really creating too much garbage for the CMS collector to cope with, then the only solution is to use an object pool to recycle the buffer objects instead of dropping them on the floor for the GC to deal with. However, you need to be careful that you don’t replace your current problem with others:

• The recycled objects may need to be “cleaned” (zeroed).
• A poorly designed object pool can be a memory leak.
• A poorly designed object pool can be a concurrency bottleneck.
• A poorly designed object pool can increase GC overheads, especially if you are running with a heap that is too small.

On the other hand, your real problem may be that your heap is too small for the application you are trying to run. If you run too close to the limit, the GC won’t reclaim much garbage each time. Since the cost of running the GC is proportional to the amount of NON-garbage, it is easy to see that the GC’s efficiency is non-linear as the heap gets closer to full.