Hello Jim,

Wednesday, September 25, 2002, 10:34:17 PM, you wrote:

> Having been through the "hoard" paper and thought about it some,
> I don't think it has much to offer a multi-threaded database
> server.

> The problem that hoard addresses is thread based memory allocation
> on multi-processors to minimize avoidable processor cache contention.
> The main idea is that it maintains separate per-processor memory
> heaps, each feed large blocks from a global super-heap. The per-
> processor heaps are organized to respect hardware cache frame
> boundaries.

> While I'm sure there are many applications where the hoard technology
> is applicable, I'm quite sure multi-threaded database server are
> among them. The problem is that a database server has a large
> collection of shared data structures. Without regard to how the
> memory is allocated, once allocated, it is shared across all threads.
> To put it another way, since the memory allocated outlives individual
> thread activity (threads, of course, are recycled), any benefit
> from systematic per-processor allocation rapid disappears into the
> noise.

> The suggestion that hoard could eliminate or reduce lock overhead
> on the memory heap by per-thread heaps doesn't work since any piece
> of memory can be released by any thread, requiring a lock to release
> memory which must be respected to allocate memory.

You are wrong, at least partially. Let's consider simple case:
You have 4 heaps A, B, C and D. Even in worst case when memory is
distributed evenly between threads and heaps if you lock heap D to
deallocate some memory heaps A, B and C can still be freely used
for both allocation and deallocation.

I developed SMP allocator for my real-time medical database project
some time ago. I allocated several large heaps and chosed heap
for allocation randomly. It almost eliminated lock time for my
program. Hoard test data demonstrate even better results because
data usually has strong thread affection in OO-programs and it is
optimized for this case and seems to behave as my allocator in worst
case.

> Jim Starkey

--
Best regards,
Nickolay mailto:skidder@...