« Previous Next »

• 07-12-2009, 11:39 PM

  DF_Frederic Joined on 06-25-2009, 9:23 AM Posts 27

  Memory management for native module Reply Contact The developer of our native module have a question regarding memory management.   I know that IIS 7 have a way of allocating memory so you don't have to worry about deleting it since the server will take care of it.  For some reason that he couldn't explain, he needs to allocate memory manually with malloc (the developer has a C background only, no C++).     What he wants to knows is that if the memory is not dellallocated if anything wrong would happens. Since the module should be deleted at the end of the request and exit the process, the not deleted memory should be dropped at the same time.    I still don't find this approach clean but is it ok to do so?    Thanks for any information on the subject.

• 07-13-2009, 2:29 AM

  In reply to

  lextm Joined on 10-22-2008, 4:18 AM Shanghai, PRC Posts 1,274

  Re: Memory management for native module Reply Contact Maybe you got a wrong impression from your developer. For native IIS extension, it is a must to manage memory usage in the extension. There is no way for IIS to track memory usage of an extension. And that's why the extension developer will be responsible to memory leak from his/her extension. But IIS 7 does introduce something new. It starts to support managed extension written in .NET. We have a start kit available here, http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1302 Lex Li Support Engineer at Microsoft --------------------------- This posting is provided "AS IS" with no warranties, and confers no rights.

• 07-13-2009, 3:51 AM

  In reply to

  DF_Frederic Joined on 06-25-2009, 9:23 AM Posts 27

  Re: Memory management for native module Reply Contact Thanks for the quick reply but this didn't answer my question.  I will try to put more details.   First thanks for giving a link but we're making a native module that requires performance, so we cannot make it a managed module. Examples for a manage module will not help me in that case.   Second, IHttpContext contains a method  called AllocateRequestMemory. This method give the responsability to the IIS server to free the memory at the end of the request.  So IIS do track the memory that it allocate by itslelf, in that case, trought the AllocateRequestMemory method. Of course, if you allocate manually, IIS doesn't know about it and I'm aware of that. Here's the description from the MSDN for the method:    "The AllocateRequestMemory method allocates an amount of memory that is specified by the cbAllocation parameter and has the lifetime of the current request. The server will automatically reclaim this memory at the end of the request. "   Even though IIS7 native modules are in C++, the developer making it only knows C. So the whole program is made in a C like way, with no object at all.  For some reason, he was not able to use AllocateRequestMemory and had to use the C way with malloc for processing his information, which mean this allocated memory is not tracked by IIS.   Now back to my question, since I think a module life time should be for the length of the request, IIS should, at the least, free the module at the end of it.  If the module is freed, so should be the memory since IIS7 should not have an handle on it.  I don't like this approach but the developer  wants to do it that way and I need to confirm if his assumption is right or not.  Maybe is assomption comes from C programs that when they exit, the system regain it's memory: it will only leak if the program continue to run but at the exit all memory is given back to the system.  A request level module liftime should be for only one request only and created on a per request basic and maybe in that case the implication of releasing memory is more trouble than anything else.  If IIS7 do keep a handle on the module after the end of the request then in that case it will leak and that will be an issue.   I still don't like the approach but any information on the subject will be appreciated.

• 07-13-2009, 9:26 AM

  In reply to

  anilr Joined on 05-23-2006, 10:13 PM Redmond, WA Posts 2,247

  Re: Memory management for native module Reply Contact There is no reason that C-style code cannot use IHttpContext::AllocateRequestMemory - you just allocate the right amount and cast it to the correct type (same as malloc).  Any memory allocated using malloc etc still has to be managed by the user of malloc - there is nothing magic that IIS can do here. Anil Ruia Senior Software Design Engineer IIS Core Server

• 07-14-2009, 12:38 AM

  In reply to

  DF_Frederic Joined on 06-25-2009, 9:23 AM Posts 27

  Re: Memory management for native module Reply Contact anilr: There is no reason that C-style code cannot use IHttpContext::AllocateRequestMemory - you just allocate the right amount and cast it to the correct type (same as malloc).  Any memory allocated using malloc etc still has to be managed by the user of malloc - there is nothing magic that IIS can do here.    Thanks again Anil for your time.  I will have to discuss to with the developer to see what kind of issues he had.   But I still want to confirm if his way of thinking is correct or not: Not de-allocating the memory is not an issue when the process exit right away. They seems to do that in apache modules. I don't know if it's a C way of thinking or not but I don't know if it does apply for IIS module.  Like mentioned above, I don't really approve that approach but I want to know if it's something commonly done.

• 07-14-2009, 12:03 PM

  In reply to

  anilr Joined on 05-23-2006, 10:13 PM Redmond, WA Posts 2,247

  Re: Memory management for native module Reply Contact Unlike apache's default process model, the IIS worker process is long lived and stays around for a long time.  So memory allocated for each request has to be freed - otherwise, you are going to be out-of-memory soon. Seems like the communication could be sped up by your developer posting here directly. Anil Ruia Senior Software Design Engineer IIS Core Server

• 07-14-2009, 9:18 PM

  In reply to

  DF_Frederic Joined on 06-25-2009, 9:23 AM Posts 27

  Re: Memory management for native module Reply Contact This is exactly what I wanted to know.  So it's not the same and he will have to be careful about this. Thanks again for your comments on the subject.   anilr: Seems like the communication could be sped up by your developer posting here directly.   In normal cases I would let the developer find the information himself but since english is not his primary language and may have difficulty to communicate on this forum, I have to be the man in the middle to actually speed up the process. Unless there is a similar forum in japanese, I will have to continue to ask questions.  Is there actually one? I'm not aware of it, not that I searched extensively.