Mark-and-sweep сборка мусора до добра не доводит

http://groups.google.com/group/golang-nuts/browse_thread/thread/ab1971bb9459025d#

http://news.ycombinator.com/item?id=3805302

Особенно если её делать полным маршем по всей распределённой памяти и поиском всего, что выглядит "похоже" на 32-битный указатель. Сборщик мусора применяет довольно консервативную логику при проверке диапазонов этих указателей => при практически полной "запаковке" 2Гб адресного пространства много мусорных данных не попадают под сборку и навсегда застревают в куче долгоработающего серверного процесса => на сервере закончилась память => прилетели.

А если для серверного процесса не задан ulimit по памяти, то ядро прибьёт ещё парочку случайных демонов, пока мы прилетим. В итоге мы совсем прилетим — так, что надо будет физически нажимать reset на сервере. Для долгоработающих серверных процессов, реализованных на garbage collected programming languages, настройка ulimit по памяти — обязательна.

Предложение выкинуть Васю на мороз выбросить 32-битный код с сервера выглядит конечно хорошо, но как же архитектура ARM? Её тоже выбросить? Ну и есть VPSки с 1-2Гб ОЗУ, где применение 64-битных процессов экономически нецелесообразно.