Greeting All,
I want to achieve transparent persistence of Java objects through memory-mapped files (utilize the OS paging/swapping mechanism).
My problem is: how can I move a Java object to my memory-mapped block ? Plus, how can I force a new object instance to reside in such blocks ?
As you all know, a memory-mapped block can be seen as a byte array, and what I am really asking here is how to overlap the address space of Java objects with the one of such arrays ? So that we can still manipulate the data via objects while OS handles persistence transparently (writes dirty pages).
If Java does not allow me for this, what cross-platform & garbage-collecting OO language would you advise me to use ?
Thank you all in advance.
The only way you can do this is by using your own Java VM and adding this functionality. Of course the code that you would write would not be in Java but in the language the VM is implemented in. Quite some time ago Gemstone used this approach for their object database engine.
Todays object databases (I work on one.) don't do things this way. It's much more straightforward to enhance bytecode to track field access and to use reflection or injected methods to turn objects into some kind of serialized form. This performs quite good. If you want to support querying, you have to work with individual field values anyway to index them.
For us it would just not be doable to maintain a VM for all the platforms that we want to run on. We also couldn't possibly convince serious customers to rely their entire (banking) application on a VM that we customize.
If you are seriously interested in producing a solution based on a Java VM: There used to be an interesting Java research project for orthogonal transparent persistence called "Forest". You may be able to find old papers or even source code.
If you are looking for a different language to take "objects" from memory directly: C++ will let you do that. There are some old object databases written in C++ that use this approach. ...but hey, that's crazy stuff, using page faults to load objects. These kind of object databases produced the bad image. I hope we will turn it around again soon.