Why is checking weird bit errors important in garbage collectors?

Question

Here's a rough translation of a tweet by @xharaken.

"Space rays hit computers and mess up the bits in the memory" "hardware bugs mess up the bits in the memory" such things almost never happen, but they happen on a nearly daily basis when there are so many users using a software like [Google] Chrome. So the GC running inside Chrome has a function to check such bit anomalies.

The original:

「宇宙線が降ってきてメモリのビットが狂う」「ハードウェアのバグでメモリのビットが狂う」というのは非常にまれな現象だけど、Chromeくらいのユーザ数規模になるとけっこう日常的に起きます。なのでChromeで走ってるGCには、それらのビット異常を検知する機構をわざわざ入れてます。

I do understand that such weird errors happen, but I don't understand how or why checking such errors is important in writing a garbage collector. What I thought was the job of garbage collectors have nothing to do with data integrity in the memory. Think about it - what a garbage collector does is it wipes data in the memory that are no longer referenced. Weird bugs caused by random memory bugs is not in a, at least, say, obvious way, related to a garbage collector's job.

Perhaps so they don't waste time debugging spurious bug reports caused by random memory errors. That's why [redis runs a memory test when it crashes](http://antirez.com/news/43) — CodesInChaos, Dec 06 '15 at 10:40
@gnat if it's unclear in any case at all - don't dupe vote it, vote it unclear. Somebody following dupe chains through closures is just bad experience. — Jimmy Hoffa, Dec 06 '15 at 15:39
I am also unclear how a garbage collector would be able to check for these errors (which do occur, although rarely). This is a task for technology such as [ECC](https://en.wikipedia.org/wiki/ECC_memory). How would a garbage collector know what the contents of the memory is? All it does is look for unused blocks to reclaim. — , Dec 07 '15 at 05:14
I can find absolutely nothing beyond the assertion of the twitter post that there is any error correction for random memory corruption within Chrome's gc. Do you have any additional material to back this assertion up that one could evaluate? — , Dec 07 '15 at 16:45
I'm glad my question is answered, but still I don't see how this question is a duplicate of [this](http://programmers.stackexchange.com/questions/230863/). Sure, @gnat is the first person to have fired up that duplicate claim, and I read [his answer](http://programmers.stackexchange.com/questions/230863/what-exactly-is-the-garbage-collector-in-java/231026#231026) too. That's all about _the garbage collector's job of freeing memory with data that are unreachable or unused_. Nothing about _the garbage collector checking random bit errors in the memory_. — hello all, Dec 07 '15 at 17:21
think of what happens to gc if references it's supposed to work with are corrupted due to memory errors. What would be result of gc if these references are broken — gnat, Dec 07 '15 at 19:01
@gnat The GC would exhibit undefined behaviour when encountering corrupted references, just like plain C code would when encountering corrupted pointers. — CodesInChaos, Dec 10 '15 at 14:47

score 10 · Accepted Answer · answered Dec 06 '15 at 11:29

In any complex, memory-intensive application, random bit errors can be hellishly hard to debug. Anything that helps you detecting them is very useful when your software is deployed to millions of devices. A garbage collector is simply the point where adding functionality to detect such errors produces the smallest overhead and has a good chance of succeeding, because it's the garbage collector's job to constantly inspect the application's memory anyway.

Why is checking weird bit errors important in garbage collectors?

1 Answers1