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

[waqur]

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-битных процессов экономически нецелесообразно.

Comments

[cd-riper.livejournal.com]

сборка мусора по принципу "поиск всего, что выглядит похоже на 32-битный указатель" это лютый пиздец.
что касается ARM, полагаю, вопрос буквально ближайших пары лет переход на 64 бита. уже сегодня 2 гига RAM для топовых устройств это норма.

[waqur.livejournal.com]

ну для большинства применений ARM-процессоров энергопотребление - далеко не последний фактор, так что 32 бита на ARMе - это всерьёз и надолго, даже если и будет выпущена 64-битная версия

[waqur.livejournal.com]

наверняка фикс будет грязным хаком в стиле "вставить 4-х байтную канарейку специального вида перед каждым GC-указателем", чтобы коллектор мог быстро распознать такой указатель