Отображаемые в память файлы и прозрачное постоянство объектов Java

Question

Приветствую всех,

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

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

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

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

Спасибо всем заранее.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

Вы не можете.

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

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