Memory files and transparent persistence of Java objects

Question

Greetings to all

I want to achieve transparent durability of Java objects through memory-mapped files (use the OS swap / swap mechanism).

My problem: how can I move a Java object into my memory mapped block? Also, how can I make an instance of a new object be in such blocks?

As you all know, a block with memory mapping can be considered as an array of bytes, and what I really ask here is how to overlap the address space of Java objects with one of these arrays? So we can still manipulate data through objects, while the OS transparently performs persistence (writes dirty pages).

If Java does not allow me this, what cross-platform and garbage OO language would you recommend me to use?

Thanks to everyone in advance.

Answer 1

The only way to do this is to use your own Java virtual machine and add this functionality. Of course, the code you would write would not be in Java, but in the language in which the virtual machine is implemented. Gemstone used this approach some time ago for its database engine.

Today's object databases (I am working on one.) Do not. It’s much easier to simplify bytecode to track access to fields and use reflection or injection methods to turn objects into some kind of serialized form. It's not bad. If you want to support a query, you must work with individual field values ​​to index them.

It would be simply impossible for us to maintain a virtual machine for all the platforms on which we want to work. We also could not convince serious customers to rely on their entire (banking) application on the virtual machine that we are setting up.

If you are seriously interested in creating a Java VM-based solution: It used to be an interesting Java research project for orthogonal transparent resilience called the Forest. You can find old documents or even source code.

If you are looking for another language for directly deriving “objects” from memory: C ++ will allow you to do this. In C ++, there are several old object databases that use this approach. ... but hey, this crazy stuff using page errors to load objects. These object databases created a bad image. Hope we get it back soon.

Answer 2

It's impossible. And there are several good reasons why the runtime does not allow this.

• The memory scheme of your object is part of the internal components of the JVM. Each JVM can make its own decisions regarding layout objects. This layout may vary by version. When you create a memory card for an object in a file, you will have problems. What happens when the layout object changes? Crash, file update, magic? Ultimately, to map memory objects to files, you will need to specify a fixed mock object.
• What happens if you add / remove a field? Then the layout object changed for sure. You cannot record a memory card with an old memory layout.
• The object also has additional information, such as VTable for virtual function calls, fields for blocking states, etc. Do you also want to display them? Probably not, because this is an internal state of the runtime. This way you will need to ignore multiple bytes or shared objects. This would make the memory layout extremely complex.
• The garbage collector compresses memory to minimize fragmentation by moving objects around. Therefore, for objects there should be a "fixing" mechanism. (this is possible in .NET, for interop reasons)
• The garbage collector has been running for generations. An object that first stands out to the younger generation. As he survives, he moves to another generation. A memory mapped object will require an exception.

For all these reasons, you cannot display Java / .NET memory objects. Supporting such a feature will make the JVM / CLR extremely complex.

The JVM / CLR still gives you access to memory files in the form of an abstraction, similar to an array where you can write / read bytes. In addition, you can implement your persistence mechanism. From simple serialization to complex databases. There are object databases that are close enough to provide transparent persistence. Then the objects behave like persistent data objects / memory mapped objects.

Answer 3

You can not.

Java, by design, provides type safety and referential integrity. That is, if I have a field of reference type T, I know that this points to an instance of T. (Heap-pollution ban introduced by type erasure). This contrasts with “unsafe” languages ​​such as C ++, where it is possible that the link points to an invalid location, where this link may cause “memory corruption”.

If Java permits processing byte [] as Object , it cannot guarantee such referential integrity.