Db4o Freespace manager is a special system that is responsible for allocating, discarding, merging of space for db4o usage and keeping database size at minimum
Db4o organizes its files into variable-sized slots with one degree of indirection (pointer slots). The physical address of a pointer slot corresponds to the internal ID of the respective object. On the lowest level the database file is seen as a uniform pool of bytes, from which slots of variable size can be allocated.
Freespace manager keeps track of the portions of the database file that haven't been allocated for use and gets notified when slots are 'freed', i.e. returned back to the pool.
That is how it works:
In general case each persisted object occupies one slot. This slot contains metadata, values of direct primitive members and references to the slots of non-primitive members. What actually goes directly into a slot and what is external is not fixed and differs from version to version. However, there is one level of indirection: a reference to a non-primitive member will not refer to the member's slot directly, but rather to the 'pointer', which is an 8 byte slot containing the address in the file and the data length. The address of this pointer slot is the object's internal ID that is used for indexing, etc.
For a simple example, assume we have
class Car { String manufacturer; }
class Driver { String name; Car car; }
and an object graph like this
This will translate into four slotsDriver: name='Barrichello', car={Car: manufacturer='BMW'}
1234: [4711, length(Driver)]
4711: [Driver,'Barrichello',0815]
0815: [4321, length(Car)]
4321: [Car,'BMW']
with 1234 being the db4o ID of the driver and 0815 the ID of the car. Whenever the driver or the car object is updated, its actual slot may be stored somewhere else, but the pointer slot (the ID) will remain the same and keep track of the slot's address. (Please, note that this is a simplified example: actual implementation uses more slots and more sophisticated processing).