When using the eXtremeDB Direct Pointer Arithmetic library (DP) it is
necessary to map the shared memory segment to the same virtual memory address
in every process because in the DP implementation eXtremeDB uses actual
memory addresses (i.e. it performs pointer arithmetic) to calculate the locations of
objects in an eXtremeDB database. The pointers must be the same in every
running instance of an eXtremeDB -based application, or pointer arithmetic just
doesn’t work. Setting the dev.named.hint parameter to zero causes eXtremeDB
to determine the actual shared memory segment address. But this could fail when
called from a second process attempting to open the shared database. In this case
it is the applications responsibility to provide a valid “hint” address.
There are several ways to determine where the runtime should map the shared
memory database. Developers can use a utility provided by the operating system
to gather memory usage information (the process memory map). These utilities
will usually display the code, data and stack memory usage of each process
running on the system and the libraries it is using. It is necessary to examine the
output and pick an address outside any address space.
In any event, the memory address is an address in each process’s virtual memory.
An address should be chosen that is sufficiently far away from the data, stack and
heap segment of every process that will share the database. (Hence the default of
0x20000000 for MAP_ADDRESS; it is assumed unlikely, but not guaranteed, that
any single process will have data, stack and heap that stretch out to 0x20000000
bytes.)
The above potential issues with respect to the MAP_ADDRESS can be avoided by
using the “Offset” library instead of the Direct Pointer Arithmetic library. The
“Offset” approach calculates an offset from the beginning address of the inmemory
database, to locate objects. Therefore, it does not depend on the inmemory
database starting at a common (and known) location for all processes.
However, the DP pointer arithmetic is about 5%–15% faster than calculating
offsets.
necessary to map the shared memory segment to the same virtual memory address
in every process because in the DP implementation eXtremeDB uses actual
memory addresses (i.e. it performs pointer arithmetic) to calculate the locations of
objects in an eXtremeDB database. The pointers must be the same in every
running instance of an eXtremeDB -based application, or pointer arithmetic just
doesn’t work. Setting the dev.named.hint parameter to zero causes eXtremeDB
to determine the actual shared memory segment address. But this could fail when
called from a second process attempting to open the shared database. In this case
it is the applications responsibility to provide a valid “hint” address.
There are several ways to determine where the runtime should map the shared
memory database. Developers can use a utility provided by the operating system
to gather memory usage information (the process memory map). These utilities
will usually display the code, data and stack memory usage of each process
running on the system and the libraries it is using. It is necessary to examine the
output and pick an address outside any address space.
In any event, the memory address is an address in each process’s virtual memory.
An address should be chosen that is sufficiently far away from the data, stack and
heap segment of every process that will share the database. (Hence the default of
0x20000000 for MAP_ADDRESS; it is assumed unlikely, but not guaranteed, that
any single process will have data, stack and heap that stretch out to 0x20000000
bytes.)
The above potential issues with respect to the MAP_ADDRESS can be avoided by
using the “Offset” library instead of the Direct Pointer Arithmetic library. The
“Offset” approach calculates an offset from the beginning address of the inmemory
database, to locate objects. Therefore, it does not depend on the inmemory
database starting at a common (and known) location for all processes.
However, the DP pointer arithmetic is about 5%–15% faster than calculating
offsets.
812
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
