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,
- System.gc() option won't help because it will be called concurrently on every call to setPlayerData().
- 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...
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.
Simply set your objects to NULL after use and the Garbage Collector will automatically take care of it. Practically Garbage Collector kicks in when your objects are not accessible by the code, so it destroys them to free up space.
Java does not have delete operator. The garbage collector destroys the object automatically when the code parts do not use them anymore.
That is when an object becames unreachable, the garbage collector destroy that object and free the memory related.
I read the edit, maybe you can solve your problem with a byte[] buffers pool. So the garbage collector does not need to garbage all the time the buffers.
private LinkedList playerData = new LinkedList();
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");
byte[] buffer = playerData.removeFirst();
// here return the buffer to the pool to reuse it
}
}
If you are having problems with the garbage collector the best thing is to allocate less new memory. One way of doing this is to use object pools. Basically, reuse a buffer you no longer need instead of creating a new one.
There is no "equivalent" operator in Java. The system performs garbage collection in the background. No explicit method call will guarantee that memory will be freed immediately.
