Hacker News Reader

Comment by kogir | Hacker News Reader

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.

View on HN

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?

Reply on news.ycombinator.com