Oh yes.

Heaps for allocating textures. Object-type-specific heaps for things like sounds and models. "Smart" heaps that can invalidate their contents under memory pressure (and maybe automatically bring stuff back in, possibly speculatively). Heaps that are good for lots of small allocations. Heaps that either do or do not allow multiple threads to use them. Heaps that are position-independent and that can be used in shared memory buffers (which can be mapped to different addresses in different processes). I could go on.

I wrote a lot of the memory management stuff for the Apple Newton, and it had several types of heaps:

- A common "Macintosh-like" heap with both fixed and sliding blocks (even with a VM system managing the page for you, fragmentation matters when memory is tight). Most threads played in this heap, and keeping it sane was kind of hard.

- A couple of heaps for the kernel, for managing its objects (it's been a while, I don't remember why there was more than one).

- A heap that could supply (limited) amounts of memory for interrupt handlers.

- The NewtonScript object heap (owned by the NewtonScript environment).

I'm pretty sure there were a couple more heaps, but I've forgotten the details. Our main worry was fragmentation, and I'd say that things probably weren't segmented enough and that we needed even more heaps than we shipped with.

A heap is just a data structure. Ain't nothing magic.

I wouldn't call a heap a "data structure", though. It will lead to mighty confusion, as heap-the-data-structure has nothing to do with heap-in-which-you-allocate-memory.

The CLR has at least two that I'm aware of, the "regular" heap (not sure if it has a special name) and the Large Object Heap. Pretty sure there are unmanaged heaps associated with a single .NET process as well -- certainly there are if you are mucking around with things like managed C++.

)