> IEEMemoryManager is an internal-only interface that is used to allow other
> DLLs to interface with hosted memory operations.
>
> If you need to control memory allocations in a CLR host, what you want to
> do is to implement IHostMemoryManager on the host and follow the sample
> shown in Dino's blog (http://weblogs.asp.net/dinoviehland ) to see how to
> hook it up.
>
> Could you elaborate more on what you are trying to do?
>
> --Alessandro
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Sample code subject to http://www.microsoft.com/info/cpyright.htm
>

> Hi Flier,
>
> If you've implemented IHostMemoryManager, and you're wanting to allocate <
> 1k of memory, the best option you have available is to go to your
> IHostMalloc implementation instead of your VirtualAlloc implementation (or
> just use ye-olde-malloc). The CLR will typically do the same thing to get
> small amounts of memory from the host. The only times it wouldn't do
this
> is for allocations that need to happen during startup (before we have the
> host memory manager) or when it's using a special purpose pool (which
seems
> to be what you're wanting to get at).
>
> The special purpose allocators the CLR implements are typically very
> special purpose. One example would be the sync block cache (you could see
> this in Rotor) where we may sometimes allocate a sync block, and other
> times we have the cached sync blocks lying around. But because you're not
> allocating sync blocks, this is useless for you. And in general that's
how
> all the internal caches will go... And anyway, we don't expose the sync
> block allocator :) So I'd say if you want an allocator that's going to
> cache things you'd want to build your own special case allocator based
upon
> your usage patterns inside your host.
>
> As Alessandro mentioned the IEEMemoryManager interface is used to
> provide the hosted memory allocations to other components of the CLR. The
> most obvious one to mention would be the JIT which needs to VirtualAlloc
> memory for placing jitted code into. And as you've discovered, it just
> turns around and passes the request off to the host implementation. This
> ensures that wherever the allocation comes from in the CLR that it will
> always go through the host. I think the key thing to note here is that
> when you replace the memory manager that you implement all the memory
> allocation primitives yourself - you get complete control.
>
> Finally on the returning an error code. Yes you can return error
> codes from your VirtualAlloc implementation, but the CLR will treat that
as
> a failure to allocate the memory, and an exception will be propagated into
> managed code. So it won't bypass it, just fail it (or in other words the
> CLR will always do what your memory allocator tells it to do).
>
> Are you just trying to get performance by piggybacking on the CLR's
> allocator? Or do you have another goal in mind?
>
>
>
>