640K хватит всем

[andrzejn]

По некоторым граблям, похоже, программисты будут ходить вечно.

Те из нас, кто ещё программировали под DOS, помнят проблемы с выделением больших фрагментов памяти: всего-то свободной памяти может быть достаточно, но непрерывного свободного участка - нету, и всё. Выкручивались из этой проблемы кто как умел.

Потом пришла 32-битная архитектура с виртуальной страничной организацией памяти. На некоторое время стало хорошо: нужный фрагмент памяти собирался из свободных 4-килобайтных страниц. Не важно, как они были разбросаны по физической памяти в реальности (или даже лежали в своп-файле на диске), программа получала свой большой непрерывный кусок.

Но люди же не удовлетворяются достигнутым - они начинают подсовывать палки под всё более тяжёлые камни, пока снова спина не затрещит от натуги. У нас много свободной памяти? Отлично, загрузим в неё побольше данных! И вот уже 2G физической памяти в рабочих станциях - совсем не редкость, а это уже близко к 4G пределу виртуального адресного пространства. И проблемы фрагментации полезли снова.

Ведь с таким количеством памяти очень неудобно работать на уровне 4K страниц. Поэтому приложения обзавелись собственными менеджерами памяти, которые распределяют полученную от системы память на кусочки поменьше или побольше. И - да, если свободной памяти вообще-то хватает, но непрерывного куска нужного размера нету, то...

Справились и с этим.

Visual Studio .NET 2005 - сама по себе .NET приложение. Это значит, что у неё умный менеджер памяти со сборкой мусора. Если не хватает непрерывного участка памяти - он передвинет занятые участки, если не хватает памяти совсем - попросит у системы ещё и добавит к адресному пространству.

Но. Этот умный менеджер памяти работает поверх обычного менеджера памяти 32-битного Windows приложения, и просит дополнительные страницы не напрямую у системы, а у промежуточного менеджера.

И получается парадоксальная ситуация: VS.NET съела уже 800M памяти, ещё 600M свободны - а Visual Studio уже жалуется на нехватку памяти и отказывается работать с большим проектом.

VS.NET 2005 - глюкавое чучело.

Comments

[wiktor.livejournal.com]

Ага. Особенно я ржу, когда фотошоп жалуется на нехватку памяти - при двух гигах оперативки, и тридцати свободных гигах под своп, который никто не ограничивает. А собака порылась всё там же: количество открытых файлов, "вес" каждого файла за сотню мегабайт, и пожалте.

[livelight]

Их всех в виртуальное адресное пространство от'mmap'или, что ли?

[slobin.livejournal.com]

Анекдот времён 640K -- своп на рамдрайве. И ведь реально пользовались!

... Только каков был вопрос, если это ответ? ...

[-pk-sly.livejournal.com]

потому что разнообразные программы (те же overlapped в Борланде) умеют работать с обычной памятью и с диском, но не умеют с extended/expanded memory :)
за то, с этой памятью умеет работать ramdrive.

помню, dos4gw/Wacom-C (и go32 с чем-то ещё) были настоящим спасением!.. :)

[gds.livejournal.com]

Днём, читая это, я хотел написать совершенно другое и в совершенно другом настроении. Криворучкам бы не поздоровилось -- я бы им послал луч кровавой диареи, и они тотчас же умерли бы в диких мучениях.
Однако сейчас, ближе к вечеру, дневные яркие краски переходят в сумеречные, хоть и серые, но спокойные.

Дело в том, что программисты часто думают в O-нотации. Потому что она их бьёт очень часто. Если для документа размером N съедается O(N) памяти, то отлично. Было бы O(N^2) -- было бы вообще хреново, в случае памяти для 32-битных машин предел был бы достигнут в районе 2^16.
Вот тут и проявляется граничная ситуация, свойственная не только ВизуальнойСтудии и ФотографическомуМагазину. Практически везде в софте считается, что O(N) по объёму -- это нормально. Те же юникоды взять для примера -- ну, в 1..4 раза больше, но что ж поделать, тот же O(N), только коэффициент больше-равен единице.

Поэтому ударяться об этот предел неприятно -- вроде бы и документы около гига весят, и адресного пространства примерно столько же (2 или 3 гигабайта под виндой максимум, afair), так что вроде бы всё должно влезть, ан нет.

Но, с другой стороны, как в случае сборки мусора (когда сборка не поспевает за выделением или для сборки требуется полное копирование занятой памяти в свободную), так и в случае mmap() программист получает удобство разработки и меньшее количество глюков программы ценой абстракции.

Но идеальных абстракций практически не бывает, поэтому приходится чем-то жертвовать. Большинство сложных программ имеют свойство ударяться снизу о разные объёмы и производительности. Кроме того, есть доказанные свойства алгоритмов, ограничивающие всеобщее счастье.

(в случае mmap(), конечно, дело не в O(N), а исключительно в абстракции. но и сам mmap() зачастую вреден.)

[netch]

1. Имеет смысл обсудить где-нибудь на RSDN. Может, подскажут, какой параметр подкрутить.
2. 800М - это по сумме объектов? В любом случае странные цифры - не должно быть такой сильной фрагментации при достаточно крупных промежуточных блоках - ну разве что менеджер (который промежуточный) решил их как-то хитро выровнять.

[andrzejn]

800M - это общая занятая процессом память, по данным Task Manager.