Hi, just a small comment. As mapDB use memory mapped files (mmap) using it for offloading memory to disk is probably not a performing idea since the O/S will already cache the file in memory the file for you : https://www.varnish-cache.org/trac/wiki/ArchitectNotes
You will basicly have two memoery cache and the O/S will beat the directmemory one. My 2 cents, Julien On Wed, Nov 7, 2012 at 8:54 AM, Raffaele P. Guidi < [email protected]> wrote: > Hi and thanks for your interest and offer! I know and appreciate your > project and made plans to integrate it as disk store since the early days. > We sure need good serialization libraries, in fact, in addition to provide > support for many different ones (kryo, msgpack, protostuff, etc) we > recently welcomed lightning (an unsafe based serializer by Christophe > Engelbert) as a subproject to complement our codebase with a fast (and > in-house) choice. > > I think we have more than one reason to integrate and share code: > > > 1. DirectMemory could make good use of mapdb to serialize least > frequently used items to disk and free memory > 2. DirectMemory could implement a MapDB disk based store in addition to > the bytebuffer and unsafe ones > 3. MapDB could take advantage of DM's componentization approach to > support multiple serializers (we believe each one has its advantages in > different scenarios) > 4. MapDB could use DM to write items to an off-heap before writing to > disk (asynchronously) to improve speed > 5. We could merge our serialization efforts (I believe lightning is very > fast and worth to be considered) and provide an even better solution or > two > alternative implementations > > In both cases we would be open to contribution in different forms - just > contributing patches or with you to join us and the ASF as module or > subproject (the latter options have to undergo a formal vote by all project > members, of course) as I strongly believe that merging efforts would bring > to a better and more complete product. > > What do you think about it? > > Regards, > Raffaele >
