Hacker News Reader

Comment by RyanZAG | Hacker News Reader

Big part of the article focuses on garbage collection, low ram environments, and mobile devices. I'd just like to say that my S4 has 2GB of ram (yes, 2GB). More than likely, my next phone will have 3GB or 4GB of ram. As the author mentions, once you get to 3x-6x more physical ram than what you absolutely need, the garbage collector no longer slows down your device - in fact, it speeds it up. So I'm not sure that this is really that big a problem. RAM is one of the areas where mobile devices really are improving rapidly (the other being 3D).

That said, the article was excellent. Props to the author.

View on HN

Actually, in general as memory use increases GC takes more time, not less. It's rare that the number of objects stays constant and they just get bigger, and more objects means longer and more difficult tracing.

HN has this problem. If we use more than a quarter or third of available RAM GC destroys site performance. Switching to faster RAM helps, but adding more doesn't.

Interesting point, but as per the chart[1] and discussion in the article, the relative memory footprint does have a big effect on performance. This is mostly felt when you get more complex object graphs. If the GC only needs to run once when you finish your calculation, it only needs to sweep once. If ram is limited and the GC is forced to run 100 times, then it must sweep 100 times. This is a lot of extra work and is the main reason why GC can be slow.

In the case of HN, it sounds like you have more than enough RAM already, so you are not hitting the 'worse case' of GC that gets hit often in javascript on last generation mobile phones. The symptoms to the user are very similar to 'disk cache thrashing' and can be as bad as multiple second pauses.

You're very correct in that increasing heap size too far is also a big problem, as running GC on 64GB of ram can take seconds - freezing up everything else while it runs. There are a number of guides on tuning the JVM on servers to avoid this. The new JVM GC algorithms are also very good at this situation by default, imo.

Finally, on the issue of RAM speed: phones generally have a fixed amount of space dedicated to RAM - the 2GB chip on my S4 is the same as a 512MB chip on an older iPhone. This generally means that it is just as fast to access the 2GB of ram on an S4 compared to the 512MB on older devices. So at least on mobile, RAM speed is fairly closely related to RAM performance. I can't seem to find the benchmarks I saw earlier on this at present, anyone can confirm or deny with numbers?

[1] http://sealedabstract.com/wp-content/uploads/2013/05/Screen-...

As a general rule, as you add memory to a VM, your overall throughput grows, but unless you're extremely careful, the length of individual GC pauses may go up (which is a concern in a GUI app; you don't want to block the main thread). Of course, all of this is highly dependent on GC used.

> the 2GB chip on my S4 is the same as a 512MB chip on an older iPhone. This generally means that it is just as fast to access the 2GB of ram on an S4 compared to the 512MB on older devices

Not necessarily. Your S4 has a memory bandwidth of either 8.5GB/sec or 12.8GB/sec (depending on if it's the Exynos or Snapdragon model). An iPhone 4S has memory bandwidth of 6.4GB/sec. So, you can read your whole memory in 230ms or 158ms (in theory; other limits will show up). The 4S can read its 512MB memory in 80ms.

As memory increases GC takes far less time as you far less memory is generally still being referred to. If your GC doesn't behave like this something else is wrong.

As memory use goes up, GC takes more time. But with more RAM available, GC (under certain strategies) can take less time. It's triggered less often, but each time it's triggered, it only copies the (no-larger-than-before) 'live' set.

What kind of GC does HN/ARC use?

> As the author mentions, once you get to 3x-6x more physical ram than what you absolutely need, the garbage collector no longer slows down your device - in fact, it speeds it up. So I'm not sure that this is really that big a problem. RAM is one of the areas where mobile devices really are improving rapidly

That's not generally true. GC performance decreases with the number of objects that have to be collected. More objects (and real-life experience shows that as soon as there is more of a finite resource -- memory in this case -- users' demands will quickly lead to ti being depleted again) actually means worse performance, not more.

GC also depends heavily on the memory's speed, and on the speed of the CPU-memory interface. If those remain constant (and, again, real-life experience shows that, while they don't, they tend to get faster slower than the CPUs do), GC performance hits will actually become heavier with increased memory.

This is particularly important if you consider that you can't actually force GC in most web environments. It's up to the system to decide when it starts cleaning. If that's done on a worst-case basis (i.e. postpone collection until the memory use becomes, or looks to be on a track of becoming dangerous), increasing the amount of memory won't help for memory-intensive applications.

Per-pass performance gets worse. Overall performance gets better, because fewer passes need to be made.

> Per-pass performance gets worse. Overall performance gets better, because fewer passes need to be made.

Yes, but what the users will see is that, instead of his application occasionally "feeling funny" every five minutes or so, the application will visibly lock every ten minutes.

It's a hard lesson that Java learned a long time ago: it's ok to be reasonably fast all that time, but people will immediately begin yelling if you're fast most of the time, but suddenly you get really sluggish, even if just for a few seconds.

Which is to a large extent why Java GUIs were essentially a failure, but it still has a large niche in high-performance server apps; you can usually get away with >100ms pauses there.

Actually I think it was more related to:

- sloppy programming, the same kind we see nowadays in JavaScript

- doing everything in the main thread

- not caring to learn how to use Swing properly

- not even taking the time to switch to the native look and feel

- not caring about users and providing a rich UI experience

Well, it was an enterprise language, and quite often most of the flaws you'd get in Java GUIs were there in the previous, native versions, too. Just like they're still there in the intranet web apps that replaced a few of the Java clients.

(I know a few people who still prefer the old-fashioned mainframe terminal apps, if available. If all you have is a few colors and line-drawing characters, even programmers have a hard time messing up simple forms. Not saying that we/they don't often succeed despite this difficulty...)

Nah, the lesson I was thinking about was taught earlier, in the days of AWT. Back then, Java was fairly slow, and the garbage collector was not as sophisticated as today. When the GC started collecting, you knew.

Ah, but on those days all implementations were still plain old interpreters.

With modern Java GUI apps, you still do, as any Netbeans user could attest.

Yes. However, an iOS device feels consistently faster while using much less memory (and processor cores!)

The extra hardware eats the battery like crazy. This is all anecdotal, but its my impression after switching from an iPhone 4 to a Nexus.

On my work laptop, I have 3GB of memory, and having Chrome with Google music, Gmail and work stuff open takes up over 50% of that. Gmail and Google Music alone take up >200MB each.

So, now I'm using Firefox, and Firefox running Gmail + my work is about 700MB, or >50% reduction in memory usage over Chrome.

Additionally, I'm using Spotify desktop, which consumes about 80MB of RAM while streaming, over the Google Music webapp, which takes 200MB+.

RAM may be improving quickly for new generations of mobile devices, but many businesses still purchase the minimum specs for their employee's machines, and this sad little 3GB laptop is not even multiple years old yet.

Reply on news.ycombinator.com