On 21/09/11 11:32, Dave Reynolds wrote:
On Tue, 2011-09-20 at 17:22 +0000, David Jordan wrote:
I guess I had the wrong impression of how TDB is implemented. I thought on 64
bit environments that some of the files were memory-mapped directly into the
virtual memory space of the application process.
They are memory mapped but that doesn't mean they are all in memory
unless you have enough memory available, have a cooperative OS, and have
set appropriate options such as -XX:MaxDirectMemorySize depending on
your JVM.
-XX:MaxDirectMemorySize affects a different area of memory allocation to
memory mapped files.
Direct memory is from ByteBuffer.allocateDirect(capacity). It is really
plain old malloc'ed space - it isn't in the heap, isn't a mapped memory
segment and does not move due to GC but is free'd when it's becomes
unreachable. I've assumed that the size is fixed so the process can
grow the heap via sbrk(2) and still have a contiguous heap.
Such a direct memory ByteBuffer is in the same segment of memory as the
rest of the JVM; it is faster to access than a heap ByteBuffer. We're
thinking of using it for TDB direct mode.
Memory mapped files are also direct ByteBuffers but they aren't from
allocated space. There are two kinds of direct memory buffers in Java.
The OS manages memory mapped files via segments of the adress space -
the Java process does not allocated them and they live in memory mapped
segments of your procress.
Andy
