[haiku-appserver] Re: Shared Memory Allocation

> I just changed our pool allocator from a bunch of C code (and ugly at
> that) to a class so we can have multiple pool managers in the same
> application without conflicts. We are going the same route as R5 and
> setting up a general application area. We will eventually be moving
> BBitmap storage to this shared area to prevent a bad app from
> overwriting BBitmap data in another app, but one question still
> remains: how should we send over a large object? Should we create a new
> area, dump it there, and tell the server to look there, or should the
> client ask the app_server for a memory chunk to write to, write to it,
> and then send the message? I'm kinda concerned about overhead and I
> wondered what the rest of you gentlemen thought.

Okay, first comes my disclaimer - I have only been awake for about an hour, so 
my brain isn't on full power.  Since we are wanting to deal with potentially 
large chunks of memory, we should try to limit memory allocation and 
deallocation as much as possible, otherwise we are going to start eating up 
time mucking with memory.  Our usual strategy at work is to allocate a chunk 
of memory, hang onto it after using it, and then reuse it later (when 
necessary, we increase the size of the memory chunk).  My first thought is 
that we should have the client request a chunk of a given size and then the 
server will respond back with a chunk of at least the requested size.  The 
client then fills in the data and sends back a message.

Now that my brain is thinking a bit more, I am remembering that the purpose of 
the pool allocator was to handle some of that memory reuse that I mentioned 
before.  If we handle the allocation at the client side, then the allocator 
and all of its associated memory can (and probably should) be freed on 
application exit.  Of course, whenever a new application starts, it will need 
to have the allocator grab new memory.  If we keep the allocation on the 
server side, we could possibly have some strategy of assigning a pool 
allocator to a single application, and then after the application terminates, 
we could hang onto the allocator and save it for use with a new application.  
We could potentially reduce the amount of memory allocation and deallocation, 
but we have more messaging overhead and we would probably need some sort of 
strategy for deciding if we need to get rid of some of our spare pool 
allocators (so we don't hang onto huge amounts of unneeded memory for 
extended periods of time).

The more I right, the less sure I am about what answer I should give.  My 
current thoughts are that handling the allocation on the client side will be 
a bit simpler to implement, and would be faster on memory passing, but the 
server implementation could possibly save a bit of overhead on application 
startup (although in some cases the overhead will be the same).  So I guess 
we are probably best off if we go with the client side allocation.  Now I am 
sure that Adi will probably have some big explanation for why I am wrong ;-)


Gabe

Other related posts: