On Apr 20, 1:17 pm, JP <[email protected]> wrote: > Sure, however... if memory is released each time within the "few > calls" (as OP describes), the program might get through with whatever > it does. This assumes this function is not called in a loop or at a > high rate generally speaking. Otherwise some more serious refactoring > is in order. Dynamic creation of memory at runtime is an expensive > operation. I avoid this to a large degree and need not worry about > garbage collection too much.
The GC currently used by Dalvik is very simple. If it can't handle an allocation request, it does a GC and retries. If it still can't do it, it throws an OOM. Doing explicit GCs "in between times" isn't going to help -- either the memory is reachable or it isn't. You'd have to work hard to construct a case where something is unreachable at time T and reachable at time T+1. I don't see why a more elaborate GC would be different. There is only one situation I know of where explicit GCs can be useful for avoiding an OOM. If you have objects with finalizers, the first GC moves the object to the finalization queue. Some time later the finalizer is run and the object becomes unreachable. The next GC then removes the object and any storage it uniquely referenced. This is reason #887 why finalizers should be avoided. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
