Hi fadden, thanks for your answer and for looking things up in the dalvik source. Sounds very much like you are right.
I didn't know of dalvik.system.VMRuntime.setMinimumHeapSize() but now tried it. Invoking that with 4 MB or 5MB has no visible effect. But invoking it with 8MB solves my problem. So while my needs are fullfilled now, at least until Android 1.6 or 2.0 comes out and dropps support for setMinimumHeapSize, I had some insights I want to share: Interestingly, while doing some benchmarking it turned out that the real heap size and heap usage is not increased by this. I called setMinimumHeapSize jsut before the caching/prebuffering starts. I've compiled my app with different values and used the eclipse DDMS view to query the heap usage at three important times in my application life cycle: Step 1: Start the application and wait for the caching to be done, then GC Step 2: Open up another activity that displays a visual list, showing the first 9 objects, then GC Step 3: Scroll several times up and down through the list, until scrolling is smooth, then GC Without using setMinimumHeapSize: Step 1: 3,258 used: 2,473 Step 2: 3,445 used: 2,571 Step 3: 3,508 used: 2,639 runtime.setMinimumHeapSize(4000000); runtime.setTargetHeapUtilization(0.9f); Step 1: 3,195 used: 2,485 Step 2: 3,508 used: 2,580 Step 3: 3,508 used: 2,583 runtime.setMinimumHeapSize(5000000); Step 1: 3,250 used: 2,386 Step 2: 3,258 used: 2,517 Step 3: 3,383 used: 2,595 runtime.setMinimumHeapSize(8000000); Step 1: 3,320 used: 2,480 Step 2: 3,320 used: 2,519 Step 3: 3,320 used: 2,531 As you can see, there is now big difference in those values. Anyway, only when setting the heap to 8MB, none of my weakly referenced objects where thrown away, and in Step 3 I instantly get a smooth scrolling list. The usage is always around 76%. I noticed there is a method setTargetHeapUtilization and tried it once, supplying 0.9f as parameter. As you can see in the above numbers, doing it results in the same actual usage around 76%. with best regards, Brian schimmel On 23 Jul., 22:16, fadden <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
