[Insight-users] smart pointers and local scope

[Michael]

Thanks, a little test program allocating a char buffer and deleting it 
afterwards proved that. How can I keep track of the "used" memory in 
Unix (top obviously does not show what I want to see...)?

How are other processes affected by this behaviour of Unix? Say, I have 
a program that allocates 1 GB of memory and deletes it right afterwards, 
then it's for example waiting for user input. On a system with 0.5 GB of 
main memory and 1 GB of swap space, can I do the following?:

start program
wait until it has freed its memory and waits for user input
start the same program again (while the first process is still running)

I guess the second process should crash since there is not enogh memory 
available (main memory + swap = 1.5 GB, process1 + process2 = 2 GB, even 
though process1 already freed its memory). Is this correct? Can I do 
something against this?

Thanks,

Michael



William A. Hoffman wrote:

>Windows memory management is different than UNIX.
>With Windows, the memory is returned to the OS after delete or free,
>so programs like top show more memory.   With UNIX, the
>memory is not returned to the OS, but is kept by the program until
>exit.  The memory is still being free'ed and is available to the
>running program.
>
>-Bill
>
>
>At 10:12 AM 8/18/2004, Michael wrote:
>  
>
>>Hi,
>>
>>if I properly understand
>>
>>http://public.kitware.com/pipermail/insight-users/2003-September/004820.html
>>
>>any memory referenced by smart pointers should be released when leaving the local scope in which the smart pointers were defined. I've written the following little program:
>>
>>#include <iostream>
>>#include "itkImage.h"
>>#include "itkImageFileReader.h"
>>
>>int main(int argc, char** argv)
>>{
>>  const unsigned int Dimension = 2;
>>  typedef unsigned char PixelType;
>>  typedef itk::Image<PixelType, Dimension> ImageType;
>>  typedef itk::ImageFileReader<ImageType> ReaderType;
>>
>>  char ch;
>>
>>  std::cout << "before block" << std::endl;
>>  std::cin >> ch;
>>
>>
>>  { // local scope
>>
>>      ReaderType::Pointer reader = ReaderType::New();
>>
>>      if (argc < 2) {
>>          std::cout << "filename required." << std::endl;
>>          return -1;
>>      }
>>      reader->SetFileName(argv[1]);
>>
>>      try {
>>          reader->Update();
>>      } catch (itk::ExceptionObject &e) {
>>          std::cout << e << std::endl;
>>          return -1;
>>      }
>>
>>      std::cout << "after update: " << std::endl;
>>      std::cin >> ch;
>>  }
>>
>>  std::cout << "after block" << std::endl;
>>  std::cin >> ch;
>>
>>  return 0;
>>}
>>
>>When compiling it with Visual Studio 6 under Windows and looking at the memory usage at the points asking for input everything looks ok: The memory usage is about 1.5 MB before the local scope, about 7.8 MB after the update call and about 2.2 MB after leaving the local scope. Obviously, the image data has been released (I used the BrainProtonDensitySliceBorder20.png image, which I upscaled by a factor 10 (in each direction)). Except of the (small) difference of 0.7 MB the same amount of memory is used before and after the local scope (where do the 0.7 MB come from?).
>>
>>When I compile the program with gcc under SunOS, however, the memory usage behaves differently. "top" shows the following values:
>>
>>before block: SIZE 4888K, RES 1672K
>>after update: SIZE 10M, RES 8520K
>>after block: SIZE 10M, RES 8520K
>>
>>It seems to me, that the memory of the smart pointers was not freed after leaving the local scope. Why is the behaviour different from the one in Windows?
>>
>>Thanks,
>>
>>Michael
>>
>>
>>_______________________________________________
>>Insight-users mailing list
>>Insight-users at itk.org
>>http://www.itk.org/mailman/listinfo/insight-users
>>    
>>
>
>_______________________________________________
>Insight-users mailing list
>Insight-users at itk.org
>http://www.itk.org/mailman/listinfo/insight-users
>
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20040818/8bfbb6e3/attachment-0001.htm