Тогда в чем проблема, когда программа на каком-то объекте вызывает rem(), сразу вычистить все? Это позволит выпилить из ВМ целую подсистему.
Не каждый, а когда он заполнен до отказа.
Оверхед по памяти от 0 до 3 раз. Но вообще, меняя границы реаллока, можно добиваться разных компромиссов между оверхедем по памяти и производительностью, но в любом случае O(N) памяти и времени.
В принципе, вы можете организовать стек как односвязный список блоков, т.е. каждый блок имеет указатель на предыдущий, и буфер на, скажем, 256 элементов. Тогда оверхед по памяти вообще крошечный, время работы — О(1) на любой запрос. Единственная потеря — сложная и медленная индексация, но вам это вроде как не нужно.
Насколько я вас понял, сборщик мусора убивает только того, для кого явно вызвали rem(). Тогда зачем он вообще нужен, если после вызова rem() можно сразу очищать объект?
Вы плохо меняете размер стека. Так как реаллокация памяти работает за линию от размера буфера, у вас сейчас асимптотика — квадрат. Пример плохого теста — 1е6 раз сделать push. Чтобы ускорить работу стека до O(1) в среднем, нужно не прибавлять что-нибудь к размеру, а увеличивать его в несколько (например в 2 раза). А если, например, потребляется меньше четверти буфера — то сократить в 2 раза. По-прежнему остается недомтаток, что некоторые обращения к стеку будут медленными, но суммарно все отработаеи быстро.
Есть другие подходы, но этот самый простой.
Я на него даже иногда натыкался в 2017. Сценарий не помню, но окно Solution Explorer исчезало, а в строке состояния было что-то вроде COM component failed with HRESULT_FAIL
Можно ввести концепцию каналов.
Допустим, nightly, stable и very_old.
Найтли — последний коммит, у которого прошли тесты.
Стейбл — последний релиз.
very_old — (подставьте сюда LTS-политику дистрибутива).
И в зависимости от этого разработчик выбирает нужный канал.
С одной стороны, это в 3 раза больше места (на самом деле нет, т.к. жирные приложения все равно в одном экземпляре), но с другой — все более-менее довольны.
Естественно, делал.
Более того, недавно я даже стал этому свидетелем)
Но это же не повод отменить разграничение прав?
Аналогично, возможность понаделать небезопасных кастов не повод отказаться от защиты от инъекний на уровне типов.
А почему паника хуже чем непойманный эксепшн? И там и там аварийное завершение, и там и там стектрейс.
Оверхед по памяти от 0 до 3 раз. Но вообще, меняя границы реаллока, можно добиваться разных компромиссов между оверхедем по памяти и производительностью, но в любом случае O(N) памяти и времени.
В принципе, вы можете организовать стек как односвязный список блоков, т.е. каждый блок имеет указатель на предыдущий, и буфер на, скажем, 256 элементов. Тогда оверхед по памяти вообще крошечный, время работы — О(1) на любой запрос. Единственная потеря — сложная и медленная индексация, но вам это вроде как не нужно.
Есть другие подходы, но этот самый простой.
Для этого уже придумали хаскель)
Для вырезки секций есть что-то вродe objcopy -j.
Да и типизация из-за отсутствия дженериков иногда нуждается в подпорках
Возможно, они так борются с переполнением счетчика счетов?)
Или упарывания с шаблонами.
Я на него даже иногда натыкался в 2017. Сценарий не помню, но окно Solution Explorer исчезало, а в строке состояния было что-то вроде COM component failed with HRESULT_FAIL
Можно ввести концепцию каналов.
Допустим, nightly, stable и very_old.
Найтли — последний коммит, у которого прошли тесты.
Стейбл — последний релиз.
very_old — (подставьте сюда LTS-политику дистрибутива).
И в зависимости от этого разработчик выбирает нужный канал.
С одной стороны, это в 3 раза больше места (на самом деле нет, т.к. жирные приложения все равно в одном экземпляре), но с другой — все более-менее довольны.
хотя бы бейдж "Используем PVS"
И это не говоря о том, что ядро-то одно на всех. Непорядок. Надо каждую программу с ядром в один EFI-бинарник линковать)
Т.е. вы реально готовы к тому, что каждая программа будет тащить копию джавы, Qt или электрона (т.е. Google Chrome)?
вложенная VTx не работает, емнип.
Но для того, что это работало нормально, осталось всего ничего — проаннотировать все библиотеки для питона.
например, в Я.браузере можно было кликнуть по самой вкладке, и он проматывал страницу вверх. По второму клику — обратно вниз.
репозитории ubuntu защищены лучше, чем учетка npm. При этом они премодерируются.
Может надо просто автоматически сжимать картинки для превью?
А в самом посте отдавать как есть.
Естественно, делал.
Более того, недавно я даже стал этому свидетелем)
Но это же не повод отменить разграничение прав?
Аналогично, возможность понаделать небезопасных кастов не повод отказаться от защиты от инъекний на уровне типов.