Ann Harrison wrote:

>
> [snip]
>
> In general, you will find that InterBase doesn't use a lot of memory,
> unless you request a ridiculous number of pages for the cache. One
> of the major tasks in moving to the SuperServer architecture was
> locating and stopping all memory leaks. This is a non-problem (I
> think).
>

I just want to add some germane information to the subject of memory
allocation in SuperServer.

The internal heap memory management described by Ann in her earlier post
was argmented with a large memory allocation (LMA) mechanism. The
existing heap memory management didn't meet the design criteria
established for the SuperServer architecture.

LMA is based on OS memory-mapped allocation services. The primary
benefit is that such memory can be removed from the process address
space; an alloc()/free() only frees the memory to that process's memory
heap so that memory is still locked in that process's address space.

LMA is used in the following situations:

1) Database buffer cache. When the database is fully detached
the cache memory is entirely released to the OS. Without LMA,
a release to the heap of a 100MB of cache buffers might fragment
on a subsequent small memory allocation. The next time the 100MB
cache was requested, it wouldn't be able to use the 99.99MB free
memory fragment and an additional 100MB memory segment would have
to be additionally allocated.

[The foregoing isn't a great example anymore. I also modified
the cache allocation algorithm. A 100MB request for database
cache can be scattered across discontiguous virtual memory using
LMA (e.g. 50MB, 25MB, 20MB, 5MB).]

2) Sort buffers of 128KB. This memory is unmapped when the database
request is released.

3) Sort/merge buffers of 64KB apiece. New to 6.0 (backported to 5.6),
this prevents multi-MB merge equivalence pairs from eating memory
in the server. Again released when the database request completion.

4) Any heap-based memory request above 256KB is transparently converted
to a LMA request. If the transaction bitmaps are growing because
dynamic sweeping is disabled, the large bitmaps will be allocated
with LMA. A transaction commit/rollback unmaps the large memory
space from the server's footprint. The memory pools keep lookaside
lists of LMA allocations and release those allocations when the
memory pool is freed.

I wanted to replace the entire foundation of gds_alloc()/gds_free() from
alloc()/free() with LMA. In such a scenario, the 128KB wholesale memory
chunks which gds_alloc() divides for retail memory allocations would
have been allocated with LMA. When gds_free() noticed that a 128KB chunk
had been entirely reconsitituted, it would then unmap the memory via
LMA. Various policy decisions would have been layered on this to meet
customer requirements.

The proposal implications weren't grasped by decision makers and I had
to read in the press about dynamic memory allocation/deallocation in MS
SQL Server 7.0 years later.

Regards,
Charlie