The key word here is 'generally', which I guess wasn't clear. What I was trying to get at is, it can only happen under specific circumstances, and only if the particular system implements it.
Which means, one small object in the middle of each 4K page can completely prevent returning the memory to the OS, despite it being 99% free. "Cannot generally do X" means slightly different things when discussing theory vs practice, I guess. I don't generally use "generally" to mean "usually" :). I'm glad to hear you're working on improving the GC -- but I'm also glad you went for simple and reliable. I didn't mean to be critical; I completely endorse that strategy. A good reliable GC is a lot of work, even for a "simple" one -- and an unreliable GC is a nightmare! Thanks for the point about finalizers; that does explain it -- though it could be fixed by forcing a GC and rechecking before actually throwing the exception. Essentially, doing at a lower level what Streets of Boston was doing in his code. But you know it's there, and why, and you're addressing it, so I withdraw my suggestion to file a bug. However -- about pre-allocation: the heap from which those external objects are allocated is also potentially subject to the same fragmentation issues. That's why I suggested it *might* work around the problem, if the source of the problem happened to be fragmentation of that heap. But if the problem is that the finalizers haven't run yet, a System.gc() would be the fix. The nice thing about GC is that you can usually ignore it without paying too much of a price -- but not always. On Mar 3, 7:09 pm, fadden <[email protected]> wrote: > On Mar 3, 4:33 pm, Bob Kerns <[email protected]> wrote: > > > Generally, non-compacting GCs, and non-compacting/consolidating > > allocators in general, cannot free memory back to the OS once it's > > been used. > > I'm not entirely comfortable with that generalization. The HeapWorker > thread wakes up during idle moments and looks for 4K pages with > nothing in them. When it finds them, the memory is made available to > the system again (madvise() system call). > > The situation you're describing ("cannot") implies a rather severe > level of fragmentation; at that level you'd be hard-pressed to > allocate anything of moderate size. That doesn't generally apply. > > Better to say that compacting VMs are much better at returning memory > to the system, and avoiding situations where large allocations fail > even though there's enough total bytes available. > > > Compacting collectors solve this by moving objects around. But that > > takes processing power and increases GC-caused latency. If I recall > > correctly, Streets of Boston is correct, and the Android folk chose a > > non-compacting algorithm for these reasons. > > We chose it because it was simple and reliable. Doing it without the > disadvantages you describe takes some effort. Now that we have actual > people dedicated to working on the GC, we're able to put forth the > effort. > > > There may be things you can do. For example, it may work to allocate a > > bitmap = the largest size you need, BEFORE allocating all your other > > stuff. This will commit it to having space that large on that side of > > things, and so long as it doesn't later manage to recycle it, that may > > make it available to you later. > > The bitmap pixel data is currently implemented using the external > allocation mechanism, which means they're nowhere near the virtual > heap, but the VM is responsible for managing them. "Reserving" space > for bitmap pixels shouldn't make a difference. > > As currently implemented the pixel memory isn't discarded until the > Bitmap finalizers execute, and finalizers can't run until after the GC > has finished doing its thing, which is why sometimes allocating a > bitmap twice in a row succeeds when the first try fails. > > The external alloc stuff is also getting fixed (veterinarian-style) by > the aforementioned GC people. -- 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
