для нас LOH — это сэкономленные драгоценные мегабайты, которые спасут жизнь при всплесках потребления памяти. и дело не в фрагментации, дело в том, что то память из LOH не переиспользуется потом для маленьких объектов.
мы не можем сделать этого из-за некоторых ограничений (и не в последнюю очередь из-за произодительности), но даже если мы это сделаем через год или два, то жить надо все равно сейчас.
это другой аспект. в реальных программах так почти никогда не бывает. но вот умрут ваши объекты в LOH, но остальной программе от этого ничуть не лучше, память-то уже не вернуть.
Когда у вас OOM, то какая производительность? Тут главное, чтобы не падало. Но вообще, конечно, интересно.
А вы в Java действительно так несчастны без LOH? Мои знакомые Java-люди никак своего несчастья н выдавали, хотя мне было интересно. Расскажите, будет познавательно.
Но ваш этот пример опять же не про мой случай. Понятно, что случится OOM, потому что в определенный момент вы запросите память под объект размером больше свободной памяти, ну и что? )
именно в этом и проблема, что что-то вообще попадает в LOH. Я просто и забыл уже, что там внутри Dictionay, думал, что он методом цепочек сделан. А нет. На цепочках HashTable сделан, но он все равно хранит внутри коллекцию всех значений и всех ключей, что опять же делает его бесполезным.
понятно, что в нем количество свободной памяти не будет уменьшаться, и что? И OOM не будет. Но так вы не делаете того, что я описываю в статье. Создайте в LOH объектов на всю почти свободную память. Вызовите GC. Убедитесь, что свободной памяти столько же, сколько было до заполнения LOH. Потом попытайтесь создать немного маленьких объектов. Вот тогда будет OOM.
Упираемся в нехватку оперативной памяти мы постоянно. Потому что живем в смешанном (managed + unmanaged) окружении 32-битного приложения с сильной фрагментацией памяти. В 64-битных операционных системах это почти незаметно, на 32-битных частные (несколько раз в день у каждого пользователя) OutOfMemory.
Большие объект создаем относительно часто, потому что строим в памяти большую модель, которую надо хранить в разных контейнерах и рассматривать под разными углами. Собственно в LOH попадают только контейнеры, потому что сами объекты маленькие (зато их очень много), но учитывая, что у нас дефицит памяти, то любое попадание в LOH — это выстрел в ногу и шаг к смерти. Ведь контейнеры имеют свойства появляться ненадолго.
И про структуры (большие) в статье ни слова ;) с ними и так все понятно — не создавать.
Какая разница VRAM или физическая память? Адресное пространство процесса все равно ограничено. Проблема не в том, что что-то куда-то не свопиться, а в том, что память занята, но при этом не хранит никаких данных, что крадет адресное пространство у всей остальной части программы.
но мы же живем в managed мире, у нас другие привычки и другой взгляд на мир. а C++ приложение с этим не столкнется, т.к. у него нет разделения на хипы для маленьких и больших объектов, а в CLR есть, поэтому большие объекты «крадут» память у всех остальных.
к тому же 3GB — это на самом деле ОЧЕНЬ мало. ведь в этих 3GB у вас живут имиджи ваших DLL-ек и ваши данные, возможно еще и unmanaged данные, значит память сильно фрагментирована (особенно если DLL небольшие), а CLR аллоцирует память непрерывными кусками по 32MB или по 16MB для LOH. К тому же Gen0 и Gen1 вообще умеют жить только в целиком непрерывном куске памяти. Поэтому при наличии фрагментации памяти для CLR может остаться совсем немного места.
проблема велика, потому что адресное пространство процесса ограничено (в x86 процессах <3Gb). и если у вас оно все занято под LOH, то вы просто получите OutOfMemoryException при совершенно свободной, по сути, памяти.
а почему вы сразу не уберете галочку «Search in comments and literal strings»?
«При чем убрать галочки со строк дбмл-ки дело непростое — или кликай по всем найденным вхождениям, или с шифтом да контролом выделять их. Нельзя отменить все галочки с dbml-файла…» — а про это вообще непонятно. Там ведь дерево, если нажать space на узле, то снимаются все галочки с потомков.
мы не можем сделать этого из-за некоторых ограничений (и не в последнюю очередь из-за произодительности), но даже если мы это сделаем через год или два, то жить надо все равно сейчас.
А вы в Java действительно так несчастны без LOH? Мои знакомые Java-люди никак своего несчастья н выдавали, хотя мне было интересно. Расскажите, будет познавательно.
Но ваш этот пример опять же не про мой случай. Понятно, что случится OOM, потому что в определенный момент вы запросите память под объект размером больше свободной памяти, ну и что? )
понятно, что в нем количество свободной памяти не будет уменьшаться, и что? И OOM не будет. Но так вы не делаете того, что я описываю в статье. Создайте в LOH объектов на всю почти свободную память. Вызовите GC. Убедитесь, что свободной памяти столько же, сколько было до заполнения LOH. Потом попытайтесь создать немного маленьких объектов. Вот тогда будет OOM.
И почитайте вот это: msdn.microsoft.com/en-us/magazine/cc534993.aspx
Большие объект создаем относительно часто, потому что строим в памяти большую модель, которую надо хранить в разных контейнерах и рассматривать под разными углами. Собственно в LOH попадают только контейнеры, потому что сами объекты маленькие (зато их очень много), но учитывая, что у нас дефицит памяти, то любое попадание в LOH — это выстрел в ногу и шаг к смерти. Ведь контейнеры имеют свойства появляться ненадолго.
И про структуры (большие) в статье ни слова ;) с ними и так все понятно — не создавать.
к тому же 3GB — это на самом деле ОЧЕНЬ мало. ведь в этих 3GB у вас живут имиджи ваших DLL-ек и ваши данные, возможно еще и unmanaged данные, значит память сильно фрагментирована (особенно если DLL небольшие), а CLR аллоцирует память непрерывными кусками по 32MB или по 16MB для LOH. К тому же Gen0 и Gen1 вообще умеют жить только в целиком непрерывном куске памяти. Поэтому при наличии фрагментации памяти для CLR может остаться совсем немного места.
Тоже самое можно посмотреть с помощью CLR Profiler.
Почему уверен? Потому что читал исходники фреймофрка и MSDN.
если вот только вы память экономите, то придется все равно заморачиваться! но браво )!
«При чем убрать галочки со строк дбмл-ки дело непростое — или кликай по всем найденным вхождениям, или с шифтом да контролом выделять их. Нельзя отменить все галочки с dbml-файла…» — а про это вообще непонятно. Там ведь дерево, если нажать space на узле, то снимаются все галочки с потомков.