Android Performance Patterns: Memory Churn and Performance

One of the tricky parts about a Managed Memory language is that it regularly executes “Garbage Collection” events, which stop your executing code in order to clean up various parts of your app’s memory. Normally, these aren’t that problematic, since they’ve been tuned to be as fast, and least intrusive as possible. But lots of them, occurring over-and-over again, can quickly eat into your frame time.

In this video +Colt McAnlis talks about a common programming pattern that can…


  1. I'm the guy who runs a second thread for the mighty garbage collector every second only on PCs (Probably not the best)

  2. uhuhuhaaa for example….uhauhahah….and don't for get to…..uhauhahaha for example…
    We know that you're reading from a script. You're not acting natural enough and these uhahahaha doesn't help. Thanks for the video it was great and very informative! 🙂

  3. Whenever people tell me, that I should write better code with fewer allocations (I do that already), I get kinda grumpy. First of all: it is Java. Google does not have to redefine how java is supposed to be written. Secondly: memory allocations can be recycled within the memory manager itself. There is absolutely no reason to place this burden on the programmer, except Google its incompetence/arrogance. Thirdly, the' art' memory manager is one big mess. Aside from the fact that it can apparently not count its free memory. When memory is tight it crashes with a segfault (as opposed to a OutOfMemory Exception).

    At this moment, I even get aborts during an array-copy, after which the garbage collector tells me that it spend 3.7 seconds trying to collect garbage. Still had 6Mb free but nonetheless could not find place for 4K. The segfault happens this time at

    "main" prio=5 tid=1 Native
      | group="main" sCount=1 dsCount=0 obj=0x64a1bb40 self=0x417f7080
      | sysTid=11547 nice=0 cgrp=apps sched=0/0 handle=0x40100154
      | state=S schedstat=( 0 0 0 ) utm=2123 stm=126 core=0 HZ=100
      | stack=0xbe5ff000-0xbe603000 stackSize=8MB
      native: ??? [0xf] (???)
      at java.lang.System.arraycopy(Native method)

    yes, indeed the native arraycopy. Probably the GC screwed up memory so I don't have to expect that this is actually a bug in the arraycopy. Instead various internal pointers might just have been thrown overboard.

  4. Hey Google boys. Instead of telling me that my app is the problem. How about actually writing a decent memory manager ? All tips and tricks of the world will not help if you can't write a decent garbage collector. What triggered this: I just got the following joke of an error: java.lang.OutOfMemoryError: Failed to allocate a 7048 byte allocation with 4933392 free bytes; failed due to fragmentation (largest possible contiguous allocation 64800 bytes). Yes you read that right, even though the largest continuous block is 64800 bytes, it apparently can't find it. Such an error and this type of 'how-to' videos are the sign of a pisspoor excuse of a memory allocator. Why don't you recycle objects within the VM ? That would be easy, efficient and would solve most memory problems.

  5. I'm trying to use fabric.js on ionic, do you guys have any idea how to drop frames when the heap is growing to large? Dragging objects lags on my note 3.

Leave a Reply

Your email address will not be published. Required fields are marked *