I'd like to add: I'm glad you're here to catch me when I'm unclear (or even wrong). You do a very good job with your explanations.
I didn't mean my response below to suggest that "my wording is right" -- obviously, it failed. I was just trying to salvage my intended meaning from the wreckage. I don't think that was a good approach, either - so let me try to restate it simply, instead: Relying on a non-compacting GC to free memory back to the OS may fail due to fragmentation. Certain allocation patterns may make this problem worse -- especially over time. Changing your allocation patterns can sometimes alleviate these problems. I wish I'd said it that way to begin with. On Mar 3, 10:00 pm, Bob Kerns <[email protected]> wrote: > 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
