Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики.
Продолжая посещать сайты проектов вы соглашаетесь с нашей
Политикой в отношении файлов cookie
Обычные — да. У меня тоже обычный:) Я говорю именно обо всяких электро- и прочих приблудах. Вот они почему-то как на подбор только с такими недорамами. У нас в СПб пытались запустить велопрокат (по городу были расставлены стоянки великов, можно было брать в одном месте и ставить в другом) — так они ВСЕ были именно с такими рамами. Ибо унисекс.
Вот бы еще научились снова делать велосипедам нормальные рамы, а не «унисекс».
Я ничего не имею против «женской» рамы на женском велике, но мужчинам стандартная высокая рама удобнее. Элементарно иногда проще делать резкий маневр, слегка налегая на нее.
Ну уж нет! Твердый знак на паровозе — это как кенгурятник на джипе. Средство изничтожения невинных пешеходов. Должен быть запрещен Женевской конвенцией.
Предлагаю компромиссный вариант: спереди цепляем мягкий знак для смягчения ударов, а сзади — твердый знак для надежности конструкции.
Был какой-то старый фильм про послереволюционную эпоху. Там художники-футуристы изобретали новый футуристичный паровоз. Со словами «яркие динамичные линии в раскраске естественным образом дадут увеличение скорости».
Здесь то же самое.
>При этом я согласен, что iDisposable + using — весьма элегантный костыль для невозможности удалить объект
С точностью донаоборот. Это элегантный костыль, чтобы сообщить GC, что объект по выходе из блока больше не нужен, и его точно можно удалять, не занимаясь отслеживанием ссылок на него. И он настолько элегантен, что уже джавовцы содрали его в виде try {… Closable ...} — только слова заклинания поменяли, а суть та же:)
И да, мы *сообщаем* GC, что объект можно собрать. При этом, если нужно выделить память, и ее не хватает, обычно запускается тот самый GC, и сгребает мусор — и память выделяется. А если ее не хватает — то запрашивается еще кусок у операционной системы.
С этой точки зрения нам монопенисуально — почистили память в момент, когда мы этого захотели, или только когда она реально потребовалась.
>то эти страницы просто перемещаются в свап навсегда до смерти процесса
А какой при этом симптом? Правильно, постоянное разрастание размера процесса в памяти, пусть и частично в свопе:) О чем регулярно воют пользователи браузеров.
И если — внезапно! — только за счет чуть более разумного и эффективного выделения/перевыделения памяти получается хваленое уменьшение на 27% разрастание процесса в памяти (да, наверняка цифра синтетическая и сильно оптимистичная) без изменений в алгоритмах и структурах данных самого приложения — то это как бы намекает на крайнюю неэффективность старого аллокатора.
Программа (в среде с GC) управляет временем жизни объектов неявно, через scopes (области видимости), либо, для объектов, которые мы хотим удалить именно тогда, когда хотим — есть свои способы (смотрим интерфейс IDisplsable).
GC можно вызвать явно — вот только никто так не делает, так как результат ручного вызова GC обычно хуже, чем его работа на автомате.
Но дело не в этом. Эффективность управления памятью, в первую очередь — это способность эффективно перевыделять освобожденную память. А тут у классических менеджеров серьезная трабла — они не умеют дефрагментировать память. Выделили 2МБ, за ним еще, потом эти 2МБ освободили, и впихнули туда, скажем, 1.5МБ. Если найдем что запихнуть в оставшиеся 0.5 — хорошо. Нет — ну и фиг с ним. Положили туда 300кб — осталась дырка в 200, и так далее.
Через какое-то время непрерывной работы ЛЮБОЙ программы в такой среде выделенная память превращается в решето, мелкие дырки в котором особо ничем не заполняются, а для новых крупных объектов память заново отхватывается у системы.
Увы, это фундаментальная проблема.
Да, я чуток упростил, но дал там ссылку на Get...Array/Release....Array.
Основная мысль была в том, что я НЕ представляю, как сделать менеджер памяти обычного нативного приложения столь же эффективным, как при наличии сборщика мусора и дефрагментации на лету.
JNA (идеологически) содрана с PInvoke — в котором как раз и нет описанных грабель, потому что все передаваемые (или получаемые обратно) массивы уже изначально копируются в ходе маршалинга и GC не может их внезапно передвинуть. То есть получается (в целом) медленнее, но зато намного проще и надежнее.
Но нам-то нужен был пример, где всё плохо и падает, а это JNI:)))
Я выше кинул ссылочку на саму презентацию segment heap. А если погуглить именно сочетание Chrome/SegmentHeap, то куча новостей про то, что хром, пересобранный под эту фичу, мистическим образом с грохотом непредсказуемо падает.
>Я еще понимаю, если бы наоборот. Из нативного в managed
Не-не-не. Вот есть массив в managed. Мы вызываем через JNI (в джаве) сишный нативный код, передав на него указатель. Чтобы там читать/писать, а потом вернуться. А в этот момент подлый GC взял и передвинул его. Вот для этого уже в сишном коде массивы пинят и анпинят (pin/unpin):
http://www.iitk.ac.in/esc101/05Aug/tutorial/native1.1/implementing/array.html
>накладные расходы на такое распараллеливание очень велики
Если интересно, почитайте про Shenandoah GC
Про Segment heap — пока есть вроде только вот эта презентация:
https://www.blackhat.com/docs/us-16/materials/us-16-Yason-Windows-10-Segment-Heap-Internals.pdf
Плюс она же — в исполнении какого-то индуса, чье произношение вызывает поток крови из ушей, поэтому не советую.
>И до кучи, с хрена ли Хром — т.е. JavaScript — стал «традиционным языком»
Он им не стал. Но любая среда исполнения сама по себе — это ровно тот же unmanaged code:) Собственно, как и JVM/CLR.
>Нельзя взять объект и сдвинуть его в сторону остальные объекты его все равно будут в старом месте искать
Да. Именно поэтому столько гимора при работе с нативными вызовами из джавы и шарпа — все эти pin/unpin. И не очень понятно, как это мелкософт реализовал прозрачно для нативного кода. Они не описывают.
>Зато программы не замерзают на несколько секунд
Это устаревшие сведения. В джаве очень осторожно вводили Parallel GC, но наконец ввели, и все довольны. В шарпе режим concurrent/non-concurrent зависит от применения — сервер или клиент:
https://devblogs.microsoft.com/premier-developer/understanding-different-gc-modes-with-concurrency-visualizer/
Насчет убивания мусорных объектов — как раз деление на поколения приводит к тому, что, например, короткоживущие объекты в циклах (которые отжирают львиную долю «создал-попользовал-убил-пересоздал») действительно не убиваются, а просто пересоздаются в том же месте.
Реинкарнация в действии.
А майкрософт, судя по их презентации. НАКОНЕЦ-ТО родил хип-менеджер с делением на сегменты (по размеру выделяемых фрагментов) и — та-дам!!! — научился склеивать (coalesce) освобождаемые.
Если совсем вкратце, то память в программах выделяется динамически в некоем большом куске, который именуется кучей (heap). При этом, в языках со сборщиками мусора (C#, Java, и.д.) этот механизм вылизан до блеска, как известное место у кота — например, куча разделена на «поколения» — короткоживущие объекты, долгоживущие, небольшие, большие и так далее — за счет этого резко уменьшается необходимость перевыделения памяти, ее дефрагментации и так далее.
А вот традиционные менеджеры памяти до сих пор тупы и прожорливы — после отдачи ненужного куска обратно в хип не торопятся его переиспользовать или «ужать».
Microsoft, судя по всему, родила сегментированный хип, но поскольку он еще крив, то для его включения надо, чтобы сама программа в манифесте (заголовочной части) явно сказала, что она хочет использовать эту фичу.
По сути, это НЕ экономия памяти, а лишь более эффективный в плане дефрагментации и аллокации менеджер ее выделенияю
Тьфу, надо ж было сверлить не стенку, а там где тромб — он бы и выскочил через дырку наружу. Проблема была бы решена.
Кстати, это вроде одна и та же астронавтка. Ее таланты многогранны.
По слухам, на МКС одна сильная и независимая женщина-астронавт угробила тамошний тубзик своими прокладками.
Это тоже надо учесть при разработке. Тубзик должен быть прокладкоустойчив.
Я ничего не имею против «женской» рамы на женском велике, но мужчинам стандартная высокая рама удобнее. Элементарно иногда проще делать резкий маневр, слегка налегая на нее.
Предлагаю компромиссный вариант: спереди цепляем мягкий знак для смягчения ударов, а сзади — твердый знак для надежности конструкции.
Артемий, видимо, тоже хочет сходить на телемост и защитить стабильность.
Здесь то же самое.
С точностью донаоборот. Это элегантный костыль, чтобы сообщить GC, что объект по выходе из блока больше не нужен, и его точно можно удалять, не занимаясь отслеживанием ссылок на него. И он настолько элегантен, что уже джавовцы содрали его в виде try {… Closable ...} — только слова заклинания поменяли, а суть та же:)
И да, мы *сообщаем* GC, что объект можно собрать. При этом, если нужно выделить память, и ее не хватает, обычно запускается тот самый GC, и сгребает мусор — и память выделяется. А если ее не хватает — то запрашивается еще кусок у операционной системы.
С этой точки зрения нам монопенисуально — почистили память в момент, когда мы этого захотели, или только когда она реально потребовалась.
А какой при этом симптом? Правильно, постоянное разрастание размера процесса в памяти, пусть и частично в свопе:) О чем регулярно воют пользователи браузеров.
И если — внезапно! — только за счет чуть более разумного и эффективного выделения/перевыделения памяти получается хваленое уменьшение на 27% разрастание процесса в памяти (да, наверняка цифра синтетическая и сильно оптимистичная) без изменений в алгоритмах и структурах данных самого приложения — то это как бы намекает на крайнюю неэффективность старого аллокатора.
GC можно вызвать явно — вот только никто так не делает, так как результат ручного вызова GC обычно хуже, чем его работа на автомате.
Но дело не в этом. Эффективность управления памятью, в первую очередь — это способность эффективно перевыделять освобожденную память. А тут у классических менеджеров серьезная трабла — они не умеют дефрагментировать память. Выделили 2МБ, за ним еще, потом эти 2МБ освободили, и впихнули туда, скажем, 1.5МБ. Если найдем что запихнуть в оставшиеся 0.5 — хорошо. Нет — ну и фиг с ним. Положили туда 300кб — осталась дырка в 200, и так далее.
Через какое-то время непрерывной работы ЛЮБОЙ программы в такой среде выделенная память превращается в решето, мелкие дырки в котором особо ничем не заполняются, а для новых крупных объектов память заново отхватывается у системы.
Увы, это фундаментальная проблема.
Основная мысль была в том, что я НЕ представляю, как сделать менеджер памяти обычного нативного приложения столь же эффективным, как при наличии сборщика мусора и дефрагментации на лету.
Но нам-то нужен был пример, где всё плохо и падает, а это JNI:)))
Не-не-не. Вот есть массив в managed. Мы вызываем через JNI (в джаве) сишный нативный код, передав на него указатель. Чтобы там читать/писать, а потом вернуться. А в этот момент подлый GC взял и передвинул его. Вот для этого уже в сишном коде массивы пинят и анпинят (pin/unpin):
http://www.iitk.ac.in/esc101/05Aug/tutorial/native1.1/implementing/array.html
>накладные расходы на такое распараллеливание очень велики
Если интересно, почитайте про Shenandoah GC
Про Segment heap — пока есть вроде только вот эта презентация:
https://www.blackhat.com/docs/us-16/materials/us-16-Yason-Windows-10-Segment-Heap-Internals.pdf
Плюс она же — в исполнении какого-то индуса, чье произношение вызывает поток крови из ушей, поэтому не советую.
>И до кучи, с хрена ли Хром — т.е. JavaScript — стал «традиционным языком»
Он им не стал. Но любая среда исполнения сама по себе — это ровно тот же unmanaged code:) Собственно, как и JVM/CLR.
Да. Именно поэтому столько гимора при работе с нативными вызовами из джавы и шарпа — все эти pin/unpin. И не очень понятно, как это мелкософт реализовал прозрачно для нативного кода. Они не описывают.
>Зато программы не замерзают на несколько секунд
Это устаревшие сведения. В джаве очень осторожно вводили Parallel GC, но наконец ввели, и все довольны. В шарпе режим concurrent/non-concurrent зависит от применения — сервер или клиент:
https://devblogs.microsoft.com/premier-developer/understanding-different-gc-modes-with-concurrency-visualizer/
Насчет убивания мусорных объектов — как раз деление на поколения приводит к тому, что, например, короткоживущие объекты в циклах (которые отжирают львиную долю «создал-попользовал-убил-пересоздал») действительно не убиваются, а просто пересоздаются в том же месте.
Реинкарнация в действии.
А майкрософт, судя по их презентации. НАКОНЕЦ-ТО родил хип-менеджер с делением на сегменты (по размеру выделяемых фрагментов) и — та-дам!!! — научился склеивать (coalesce) освобождаемые.
А вот традиционные менеджеры памяти до сих пор тупы и прожорливы — после отдачи ненужного куска обратно в хип не торопятся его переиспользовать или «ужать».
Microsoft, судя по всему, родила сегментированный хип, но поскольку он еще крив, то для его включения надо, чтобы сама программа в манифесте (заголовочной части) явно сказала, что она хочет использовать эту фичу.
По сути, это НЕ экономия памяти, а лишь более эффективный в плане дефрагментации и аллокации менеджер ее выделенияю
Кстати, это вроде одна и та же астронавтка. Ее таланты многогранны.
Это тоже надо учесть при разработке. Тубзик должен быть прокладкоустойчив.
«Сорвано строительство главного таможенного ЦОДа. Сверхдешевый подрядчик провалил контракт»
Занавес:)