Java VM перемещают объекты в память, и раз так - как?
Одна из проблем, которую вы должны знать, заключается в том, что при импорте пространства имен через web.config в папке Views это namespace импортируется JUST для представлений в этой папке. Если вы хотите импортировать namespace в представлениях области, вы также должны импортировать этот файл namespace в файл web.config этой области, расположенный в папке Views области;
6 ответов
В отношении комментария выше об обходе "кучи".
Другой GC делают это различные пути.
Обычно коллекторы копирования, когда они обходят "кучу", они не обходят все объекты в "куче". Скорее они обходят ЖИВЫЕ объекты в "куче". Импликация - то, что, если это достижимо от "корневого" объекта, объект жив.
Так, на данном этапе, должен коснуться всех живых объектов так или иначе, поскольку это копирует их от старой "кучи" до новой "кучи". После того как копия живых объектов сделана, все, что остается в старой "куче", или объекты, уже скопированные или мусор. В той точке старая "куча" может быть отброшена полностью.
два основных преимущества этого вида коллектора - то, что он уплотняет "кучу" во время фазы копии, и что он только копирует живущие объекты. Это важно для многих систем, потому что с этим видом коллектора, объектное выделение очень дешево, буквально немного больше, чем постепенное увеличение указателя "кучи". Когда GC происходит, ни один из "мертвых" объектов не копируется, таким образом, они не замедляют коллектор. Также оказывается в динамических системах, что существует намного больше мало, временный мусор, чем существует давнишний мусор.
кроме того, путем обхода живого графа объектов, Вы видите, как GC может "знать" о каждом объекте, и отслеживать их в любых целях корректировки адреса, выполненных во время копии.
Это не форум для разговора глубоко о механике GC, как это - нетривиальная проблема, но это - основы того, как работает коллектор копирования.
А копирование поколений GC поместит "более старые" объекты в различную "кучу", и они заканчивают тем, что собирались менее часто, чем "более новая" "куча". Теория состоит в том, что длительные объекты продвинуты на старшие поколения, и будьте забраны все меньше и меньше, улучшив полную производительность GC.
кажется, что Вы ищете распределенный кэш, что-то как терракота или Java оракула objece кэш (раньше tangersol).
Если Вы готовы пойти, что в глубине души, можно смотреть к документам архитектуры Кэша JBoss и захватить часть ее исходного кода как ссылка.
Это не точно, что Вы описали, но это работает очень похожее.
Вот ссылка.
http://www.jboss.org/jbosscache/
я надеюсь, что это помогает.
Ключевое слово, которое Вы после, "уплотняет сборщик "мусора"". JVMs разрешают использовать один, означая, что объекты могут быть перемещены. Консультируйтесь с руководством своей JVM, чтобы узнать, делает ли Ваше, и видеть, существуют ли любые параметры командной строки, которые влияют на него.
концептуально самый простой способ объяснить уплотнение состоит в том, чтобы предположить, что сборщик "мусора" замораживает все потоки, перемещает объект, "кучу" поисков и стек для всех ссылок на тот объект, и обновляет их с новым адресом. На самом деле это более сложно, чем это, так как для производительности обосновывает, что Вы не хотите выполнять полную развертку с остановленными потоками, таким образом, возрастающий сборщик "мусора" сделает работу при подготовке к уплотнению каждый раз, когда это может.
, Если Вы интересуетесь косвенными ссылками, Вы могли бы запустить путем исследования слабых и мягких ссылок в Java и также удаленных ссылок, используемых различными системами RPC.
Мне было бы любопытно знать больше о Ваших требованиях. Как другой ответ предполагает, Терракота может быть точно, что Вы ищете.
существует тонкое различие однако между тем, что Терракота обеспечивает, и что Вы просите, таким образом мой запрос.
различие - то, что, что касается Вас, Терракота не обеспечивает "удаленные" ссылки на объекты - на самом деле, целое "удаленное" понятие RMI, JMS, и т.д. совершенно отсутствует при использовании Терракоты.
Скорее в Терракоте, все объекты находятся в большой виртуальной "куче". Потоки, есть ли на Узле 1 или Узле 2, Узел 3, Узел 4, и т.д. у всех доступ к какому-либо объекту в виртуальной "куче".
нет никакого специального программирования для изучения, или специальные API, объекты в "виртуальной" "куче" имеют точно то же поведение как объекты в локальной "куче".
Короче говоря, то, что обеспечивает Терракота, является моделью программирования для нескольких JVMs, которая управляет точно тем же как модель программирования для единственной JVM. Потоки в отдельных узлах просто ведут себя как потоки в единственном узле - объектные мутации, синхронизируемые, ожидайте, уведомьте, что все ведут себя точно то же через узлы как как через потоки - нет никакого различия.
, Кроме того, в отличие от любого решения прибыть перед ним, ссылки на объект сохраняются через узлы - значение, что можно использовать ==. Именно весь часть поддержания Модели памяти Java через кластер является фундаментальным требованием для создания "регулярного" Java (например, POJOs, синхронизируемые, ожидайте/уведомляйте), работа (ничего подобного не работает, если Вы не делаете / не может сохранить объектные идентификационные данные через кластер).
, Таким образом, вопрос возвращается Вам для дальнейшего совершенствования requiements - для того, какая цель Вам нужны "удаленные" указатели?
(Практически) Любой собрал "мусор", система должна переместить объекты в памяти, чтобы упаковать их более плотно и избежать проблем фрагментации.
то, На что Вы смотрите, является очень большим и сложным предметом. Я предположил бы, что Вы читаете на существующем стиле удаленного объекта API: дистанционная работа.NET и идущий далее назад технологии как CORBA
, Любое решение для отслеживания ссылок будет сложным при необходимости иметь дело со всеми видами отказа, которые существуют в распределенных системах. JVM не должна волноваться о внезапном нахождении, что она не видит половину своей "кучи", потому что сетевой коммутатор дал незначительный сбой.
, Когда Вы развертываете в дизайн, я думаю, что многое из него сведется, как Вы хотите обработать различные случаи возникновения отказов.
Ответ на комментарии:
Ваш вопрос говорит о том, чтобы хранить объекты распределенным способом, который является точно, к чему обращаются дистанционная работа.NET и CORBA. По общему признанию никакая миграция поддержки технологий этих объектов (AFAIK). Но они оба имеют дело экстенсивно с понятием объектных идентификационных данных, которые являются критической частью любой распределенной объектной системы: как различные части системы знают, о каких объектах они говорят.
я не чрезмерно знаком с деталями сборщика "мусора" Java, и я уверен, Java и сборщики "мусора".NET имеют большую сложность в них для достижения максимальной производительности с минимальным влиянием на приложение.
Однако основная идея для сборки "мусора":
- VM мешает всем потокам выполнить управляемый код
- , Он выполняет анализ достижимости от набора известных 'корней': статические переменные, локальные переменные на всех потоках. Для каждого объекта это находит, что следует за всеми ссылками в объекте.
- Любой объект, не определенный анализом достижимости, является мусором.
- Объекты, которые все еще живы, могут затем быть спущены в памяти для упаковки их плотно. Это означает, что любые ссылки на эти объекты также должны быть обновлены с новым адресом. Путем управления то, когда мусор собираются, может произойти, VM может гарантировать, что нет никаких ссылок на объект 'в воздухе' (т.е. сохраненный в регистре машины), который вызвал бы проблему.
- , После того как процесс завершен, VM запускает потоки, выполняющиеся снова.
Как улучшение этого процесса VM может выполнить сборку "мусора" поколений, где отдельная "куча" сохраняется на основе 'возраста' объекта. Объекты запускаются в "куче" 0 и если они переживают несколько GCs затем перемещение в "кучу" 1 и в конечном счете помещать в "кучу" 2 (и так далее-.NET поддерживает 3 поколения только хотя). Преимущество этого состоит в том, что GC может выполнить "кучу" 0 наборов очень часто и не иметь для волнения о выполнении работы для доказательства долговечных объектов (которые закончились в "куче" 2), все еще живы (который они почти наверняка).
существуют другие улучшения для поддержки параллельной сборки "мусора", и детали вокруг распараллеливают, которые на самом деле выполняют неуправляемый код, когда GC планируется, которые добавляют намного больше сложности к этой области.