On Jul 23, 5:50 am, "[email protected]" <[email protected]> wrote: > Actually, something like that happens: > Object 1 is cached > Object 2 is cached > Object 3 is cached > Object 4 is cached > Object 5 is cached > Objects 1 to 4 are cleared by the GC > Object 6 is cached > Object 7 is cached > Object 8 is cached > Object 9 is cached > Objects 5 to 8 are cleared by the GC > and so on.
I don't believe this is the desired behavior. Looking at tryMalloc() in dalvik/vm/alloc/Heap.c, it initially calls gcForMalloc(false), which should not be attempting to collect soft references. Only later, when confronted with the possibility of throwing OOM, does it call gcForMalloc(true). Hmm. In dvmHeapSizeChanged() there's a "SOFT_REFERENCE_GROWTH_SLACK" value that appears to be trying to strike a balance between expanding without limit and collecting objects. If there's no cap we might fill 16MB with softly-reachable objects before we discard any of them, which isn't desirable on a device that has multiple applications resident in memory. It appears the function wants the GC to collect "some" of the soft references, which sounds good, but it looks like SR_COLLECT_SOME doesn't receive special treatment during the mark & sweep. In the current implementation, it's all or nothing. So my guess is you've got more than 128KB of softly-reachable objects (i.e. the things that are softly referenced, and the things that are only reachable through them). When the GC has to choose between expanding the current heap size and chucking the soft references, it's choosing to discard "some", which in the current implementation means "all". The observed behavior changes after you have a bunch of other stuff allocated, because the "soft limit" is higher, and the GC doesn't have to choose between expanding the heap and collecting the soft references. You might be able to work around this behavior by calling dalvik.system.VMRuntime.setMinimumHeapSize() (which really shouldn't be exposed in the API, but there it is). If you start it out at 4MB that might prevent you from thrashing like this right after the app starts up. I think the issue will come back if you manage to get close to the soft limit again, but I don't think that's avoidable without a change to the GC behavior. (There are some kluges you could employ to suppress the behavior, like periodically grabbing hard references to all cached items, allocating something large, discarding it, and un-refing the cache entries, but that's ugly and might not work anyway.) I'll file a bug against the GC. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
