Re: CoTaskMemAlloc failure??

Hi Lawrence

Unfortunately I'm writing a COM server which implements a standard published interface. In this particular case the client would have specified a time range and I need to return as much of the data from the underlying DB for that time period as I can. This can be very large - even more than the 800k I'm allocating now. So I really need to know how much I can allocate in one go - the more the better really. How can I quantify this? How can I determine the limit at any given time and allocate only that amount of space??

And yes, I am considering a design rethink - that's why I asked the question originally!! ;-)

Regards,
Ronan

Lawrence Groves wrote:
"Ronan Bohan" <ronan.bohan@xxxxxxxxxxxxx> wrote in message news:OWA%23g77kFHA.3288@xxxxxxxxxxxxxxxxxxxxxxx

Hi Kim

Thanks for the reply. I had thought about fragmentation but we're talking about quite a small block of memory here - just 800k - with nearly 1.5GB available. So I don't think that's a reasonable explanation. Another thought that crossed my mind was to do with alignment issues. But again with so much free space this can't be the real reason.


800k is a big chunk of RAM, if its got to be contiguous. Does it really have to be? What are you trying to store? I would suggest a design rethink. Maybe you can store your data in linked blocks and then avoid the necessity of having contiguous storage??



One interesting thing I've noticed since about my test app is that if I replace the CoTaskMemAlloc/Free with calls to new[]/delete[] (allocating using the same strategy) my system becomes very unstable very quickly. It's as though new & delete are aggressive in terms of how the allocate memory compared to CoTaskMemAlloc/Free. In both cases I see the memory footprint grow but the COM alloc function don't cripple the machine and it recovers almost immediately upon calling free. 


Regardless of the allocator, the problem above will likely still exist.



Seems to me like CoTaskMemAlloc/Free use a different heap and/or strategy for memory allocation. But what I'm after is understanding the limits and how to figure out if I'm near or approaching them (because I don't think I am but yet I'm seeing reasonable requests denied)


From a design point of view the first thing you should consider is 'what am I going to do when I run out of storage'? Trust me, it *will* happen, so play defensive and try to come up with a different strategy, maybe as above.

Loz.


.

Relevant Pages

  • Re: Software memory management reengineering
    ... I can't even think of a good reason for 'shutdown' to allocate ... memory dynamically. ...
    (comp.lang.c)
  • Re: CoTaskMemAlloc failure??
    ... > with so much free space this can't be the real reason. ... > It's as though new & delete are aggressive in terms of how the allocate ... > memory compared to CoTaskMemAlloc/Free. ...
    (microsoft.public.vc.atl)
  • Need advice on ORA-04030 and pga_aggregate_target parameter
    ... memory when trying to allocate 16396 bytes (koh-kghu call,pmuccst: ... PGA memory freed back to OS 1027295150080 bytes ... No processing caused anything but optimal executions, ... What can be the possible reason for this error and how we determine ...
    (comp.databases.oracle.server)
  • Re: CoTaskMemAlloc failure??
    ... I had thought about fragmentation but we're talking about quite a small block of memory here - just 800k - with nearly 1.5GB available. ... But again with so much free space this can't be the real reason. ... It's as though new & delete are aggressive in terms of how the allocate memory compared to CoTaskMemAlloc/Free. ...
    (microsoft.public.vc.atl)
  • Tru64 issues with Infinite limits
    ... An automated test in my nightly build was failing due to Out of Memory ... Cannot allocate block 146 ...
    (comp.unix.tru64)
Loading