640K хватит всем
Friday, 17 August 2007 13:06![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrzejnПо некоторым граблям, похоже, программисты будут ходить вечно.
Те из нас, кто ещё программировали под DOS, помнят проблемы с выделением больших фрагментов памяти: всего-то свободной памяти может быть достаточно, но непрерывного свободного участка - нету, и всё. Выкручивались из этой проблемы кто как умел.
Потом пришла 32-битная архитектура с виртуальной страничной организацией памяти. На некоторое время стало хорошо: нужный фрагмент памяти собирался из свободных 4-килобайтных страниц. Не важно, как они были разбросаны по физической памяти в реальности (или даже лежали в своп-файле на диске), программа получала свой большой непрерывный кусок.
Но люди же не удовлетворяются достигнутым - они начинают подсовывать палки под всё более тяжёлые камни, пока снова спина не затрещит от натуги. У нас много свободной памяти? Отлично, загрузим в неё побольше данных! И вот уже 2G физической памяти в рабочих станциях - совсем не редкость, а это уже близко к 4G пределу виртуального адресного пространства. И проблемы фрагментации полезли снова.
Ведь с таким количеством памяти очень неудобно работать на уровне 4K страниц. Поэтому приложения обзавелись собственными менеджерами памяти, которые распределяют полученную от системы память на кусочки поменьше или побольше. И - да, если свободной памяти вообще-то хватает, но непрерывного куска нужного размера нету, то...
Справились и с этим.
Visual Studio .NET 2005 - сама по себе .NET приложение. Это значит, что у неё умный менеджер памяти со сборкой мусора. Если не хватает непрерывного участка памяти - он передвинет занятые участки, если не хватает памяти совсем - попросит у системы ещё и добавит к адресному пространству.
Но. Этот умный менеджер памяти работает поверх обычного менеджера памяти 32-битного Windows приложения, и просит дополнительные страницы не напрямую у системы, а у промежуточного менеджера.
И получается парадоксальная ситуация: VS.NET съела уже 800M памяти, ещё 600M свободны - а Visual Studio уже жалуется на нехватку памяти и отказывается работать с большим проектом.
VS.NET 2005 - глюкавое чучело.
Те из нас, кто ещё программировали под DOS, помнят проблемы с выделением больших фрагментов памяти: всего-то свободной памяти может быть достаточно, но непрерывного свободного участка - нету, и всё. Выкручивались из этой проблемы кто как умел.
Потом пришла 32-битная архитектура с виртуальной страничной организацией памяти. На некоторое время стало хорошо: нужный фрагмент памяти собирался из свободных 4-килобайтных страниц. Не важно, как они были разбросаны по физической памяти в реальности (или даже лежали в своп-файле на диске), программа получала свой большой непрерывный кусок.
Но люди же не удовлетворяются достигнутым - они начинают подсовывать палки под всё более тяжёлые камни, пока снова спина не затрещит от натуги. У нас много свободной памяти? Отлично, загрузим в неё побольше данных! И вот уже 2G физической памяти в рабочих станциях - совсем не редкость, а это уже близко к 4G пределу виртуального адресного пространства. И проблемы фрагментации полезли снова.
Ведь с таким количеством памяти очень неудобно работать на уровне 4K страниц. Поэтому приложения обзавелись собственными менеджерами памяти, которые распределяют полученную от системы память на кусочки поменьше или побольше. И - да, если свободной памяти вообще-то хватает, но непрерывного куска нужного размера нету, то...
Справились и с этим.
Visual Studio .NET 2005 - сама по себе .NET приложение. Это значит, что у неё умный менеджер памяти со сборкой мусора. Если не хватает непрерывного участка памяти - он передвинет занятые участки, если не хватает памяти совсем - попросит у системы ещё и добавит к адресному пространству.
Но. Этот умный менеджер памяти работает поверх обычного менеджера памяти 32-битного Windows приложения, и просит дополнительные страницы не напрямую у системы, а у промежуточного менеджера.
И получается парадоксальная ситуация: VS.NET съела уже 800M памяти, ещё 600M свободны - а Visual Studio уже жалуется на нехватку памяти и отказывается работать с большим проектом.
VS.NET 2005 - глюкавое чучело.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: Saturday, 18 August 2007 00:27 (UTC)за то, с этой памятью умеет работать ramdrive.
помню, dos4gw/Wacom-C (и go32 с чем-то ещё) были настоящим спасением!.. :)