Modern GCs do not add much overhead when excess memory is available. When the app itself consumes a lot of memory and there is little room available, the GC gets stressed and eats too much CPU time. The chart in the link (taken from some paper) depicts this. The problem is the GC under low memory conditions, not Java.

Yes, the link is about JS. But there are relevant pieces.

Quote from the article: "If you want to process camera images on Android phones for real-time object recognition or content based Augmented Reality you probably heard about the Camera Preview Callback memory Issue. Each time your Java application gets a preview image from the system a new chunk of memory is allocated. When this memory chunk gets freed again by the Garbage Collector the system freezes for 100ms-200ms. This is especially bad if the system is under heavy load (I do object recognition on a phone – hooray it eats as much CPU power as possible). If you browse through Android’s 1.6 source code you realize that this is only because the wrapper (that protects us from the native stuff) allocates a new byte array each time a new frame is available. Build-in native code can, of course, avoid this issue."