отображенный в памяти файлов и Transparent Постоянство Java Objects

Question

Приветствие Все,

Я хочу, чтобы достичь прозрачного Постоянство объектов Java через отображенные в памяти файлы (использовать подкачку OS/замена механизма).

Моя проблема: как я могу перенести объект Java в свой блок с отображением памяти? Плюс, как я могу заставить экземпляр нового объекта находиться в таких блоках?

Как вы все знаете, блок с отображением памяти можно рассматривать как массив байтов, и то, что я действительно спрашиваю здесь, - это совмещение адресного пространства объектов Java с одним из таких массивов? Так что мы все еще можем манипулировать данными через объекты, в то время как ОС прозрачно выполняет персистентность (записывает грязные страницы).

Если Java не позволяет мне для этого, то какой кросс-платформенный & язык сбора данных для сбора мусора вы бы посоветовали мне использовать?

Благодарим вас заблаговременно.

Answer 1

Единственный способ сделать это - использовать свою собственную виртуальную машину Java и добавить эту функциональность. Конечно, код, который вы бы пишете, не был бы на Java, а на языке, на котором была реализована виртуальная машина. Некоторое время назад Gemstone использовал этот подход для своего механизма базы данных объектов.

Сегодняшние базы данных объектов (я работаю над одним.) Не делают этого таким образом. Гораздо проще упростить байт-код для отслеживания доступа к полям и использовать методы отражения или впрыска, чтобы превратить объекты в какую-то сериализованную форму. Это неплохо. Если вы хотите поддерживать запрос, вы должны работать с отдельными значениями полей, чтобы их индексировать.

Для нас было бы просто невозможно поддерживать виртуальную машину для всех платформ, на которых мы хотим работать. Мы также не могли убедить серьезных клиентов полагаться на все свое (банковское) приложение на виртуальную машину, которую мы настраиваем.

Если вы серьезно заинтересованы в создании решения на основе Java VM: Раньше был интересным исследовательский проект Java для ортогональной прозрачной стойкости, называемый «Лес». Вы можете найти старые документы или даже исходный код.

Если вы ищете другой язык для непосредственного получения «объектов» из памяти: C++ позволит вам это сделать. На C++ есть несколько старых баз данных объектов, которые используют этот подход. ... но эй, это сумасшедшие вещи, используя ошибки страницы для загрузки объектов. Эти базы данных объектов создавали плохое изображение. Надеюсь, что мы скоро вернем его.

Answer 2

Это не возможно. И есть несколько веских причин, почему среда выполнения этого не позволяет.

• Макет памяти вашего объекта является частью внутренних элементов JVM. Каждая JVM может принимать собственные решения относительно объектов макета. Этот макет может меняться по версиям. Когда вы создадите карту памяти для объекта в файл, у вас возникнут проблемы. Что происходит, когда объект-макет изменился? Сбой, обновление файла, волшебство? В конечном итоге для отображения объектов памяти в файлы потребуется указать фиксированный объект-макет.
• Что произойдет, если вы добавите/удалите поле? Тогда объект-макет изменился точно. Вы не можете записать карту памяти со старой памятью.
• Объект также имеет дополнительную информацию, такую ​​как VTable для виртуальных функциональных вызовов, поля для состояний блокировки и т. Д. Хотите ли вы также их отобразить? Наверное, нет, потому что это внутреннее состояние времени выполнения. Таким образом, вам нужно будет игнорировать несколько байтов или разделенных объектов. Это сделало бы макет памяти чрезвычайно сложным.
• Сборщик мусора уплотняет память, чтобы минимизировать фрагментацию, перемещая объекты вокруг. Поэтому для объектов должен быть «фиксирующий» механизм. (это возможно в .NET, для interop-причин)
• Сборщик мусора работает в поколениях. Объект, который сначала выделяется на молодое поколение. По мере того, как он выживает, он перемещается в другое поколение. Объект с отображением памяти потребует исключения.

По всем этим причинам вы не можете использовать Java/.NET-объекты памяти. Поддержка такой функции сделает JVM/CLR чрезвычайно сложным.

JVM/CLR по-прежнему предоставляет вам доступ к файлам с памятью в виде абстракции, подобной массиву, где вы можете писать/читать байты. Кроме того, вы можете реализовать свой механизм персистентности. От простой сериализации до сложных баз данных. Существуют объектные базы данных, которые довольно близки, чтобы обеспечить прозрачную настойчивость. Затем объекты ведут себя как постоянные объекты данных/объекты с отображением памяти.

Answer 3

Вы не можете.

Java, по дизайну, обеспечивает безопасность и ссылочную целостность. То есть, если у меня есть поле ссылочного типа T, я знаю, что это указывает на экземпляр T. (Запрет кучи-загрязнения, введенный стиранием типа).Это контрастирует с «небезопасными» языками, такими как C++, где вполне возможно, что ссылка указывает на недопустимое местоположение, где эта ссылка может вызвать «повреждение памяти».

Если Java разрешает обрабатывать байт [] как Object, он не может гарантировать такую ​​ссылочную целостность.