eXtremeDB Memory management

The eXtremeDB runtimeprovides its own optimized memory management. It

includes a low-level pagemanager and a heap manager. When a database

instance is created,memory space is allocated on the heap or claimed (declared)

in static memory.This memory is formatted by the runtime and used the entire

time the instanceexists. A small portion of this memory is dedicated for database

runtime controlstructures. The page manager controls the remainder along with

any extensions. Thememory is partitioned into pages, each page having the same

size (page_size). Thepage manager is a very fast and efficient mechanism. It

allows any pagereleased by any consumer (for example, by a tree index) to be

used immediately byany other consumer (for example, by the object layout

manager). Thepage_size parameter is passed to the runtime at the time the

database instance iscreated and affects all the derived memory managers.

As a rule of thumb,page_size should be between 60 and 512 bytes; a 100 byte

page works fine inmost situations. The page_size should be a multiple of 4, and

if it is not theruntime will adjust it internally. Almost all memory used by the

database instance isused to store objects or index data. The overhead imposed by

the index memorymanagers is not really affected by the page_size when it is

larger than 60 bytes.This is because the fixed part of the index control data is

typically between 4and 12 bytes per page. Therefore, the page size mostly affects

the overhead imposedby object layout managers.

Objects that havedynamic data fields, such as strings or vectors, always occupy

whole pages. Multiplefixed size objects can share a page. This means, for

example, that if thepage size is 100 bytes and some object with dynamic fields

took 440 bytes includingall control data, then 60 bytes (= 5*100 – 440) would be

wasted. It is notreally possible to determine in advance the exact optimal page

size. It depends onwhat will be the object size distribution at runtime: what will

be the actual sizesof the dynamic data, what will be the dynamic sequence of

operations, and whattype of objects will be stored most frequently, etc. To

determine runtimememory requirements the calculator tool is provided to do

memory calculationsusing the actual application database dictionary and

specified numbers ofobjects. (The database calculator functionality is described

in section “DatabaseStatus and Statistics Interfaces” of Chapter 4.) The statistics

generated by the calculator make it easy toadjust the page size parameter in order to optimize memory use.