bugDotGNU Portable.NET - Bugs: bug #20250, Garbage Collector Doesn't Reclaim...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #20250: Garbage Collector Doesn't Reclaim Memory

Submitter:  Nick Lee <nick_lee>
Submitted:  Mon 25 Jun 2007 10:54:19 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Discussion locked!

Jump to the original submission

  Spam posted by anonymous
Wed 27 Jun 2007 07:42:17 AM UTC, comment #11: 

That's a good point, we are running 0.7.4 - I'll try it on 0.8.0 and see if it fixes the problem!

Nick Lee <nick_lee>
Tue 26 Jun 2007 04:55:33 PM UTC, comment #10: 

Incidentally, System.GC.GetTotalMemory answers the heapsize in pnet; see engine/lib_gc.c, support/hb_gc.c, and libgc/include/gc.h.

I changed your test to loop 20 times, with a 1MB, then 10MB, then 50MB buffer, but was unable to get the heap to grow beyond 1527808, 10977280, and 122130432 bytes, respectively.  This is with pnet-0.8.0 on i686-mandriva-linux-gnu.  Perhaps there is something wrong that is platform-specific?

I noticed in GCTest3embedded.log that you are running 0.7.4, at least on that embedded system.

Stephen Compall <S11001001>
Group Member
Tue 26 Jun 2007 11:19:12 AM UTC, comment #9: 

Forgot to mention the last test also results in the warning:

"GC Warning: Repeated allocation of very large block (appr. size 150003712): May lead to memory leak and poor performance.

Nick Lee <nick_lee>
Tue 26 Jun 2007 11:14:17 AM UTC, comment #8: 

Another test I've tried is this:

Allocate a large amount of memory.
Remove all references to it.
Repeat several times.

The result is that each time the memory is allocated, the heap is increased by that amount, even though the previous piece of memory should have been garbage collected by now (I've even done GC.Collect()).  Eventually, the attempt to allocate the large amount of memory fails and OutOfMemoryException is thrown.

Nick Lee <nick_lee>
Tue 26 Jun 2007 08:18:09 AM UTC, comment #7: 

Ok, that's fair enough, but I'm also printing out the "bytes allocated" returned from the GC.TotalMemory function, and this number is constantly increasing too, which would suggest that it's not unallocating anything.  It's just that if we run our application for long enough, it runs out of memory, yet as far as the logs are concerned, nothing is being reclaimed!

Nick Lee <nick_lee>
Tue 26 Jun 2007 08:07:44 AM UTC, comment #6: 

I apologize if I misunderstand you, but:

"heapsize" refers to the size of the heap, not the number of allocated bytes in the heap; it includes free bytes.

This number is only loosely associated with bytes allocated.  For example, if a GC finds infant mortality is too low, it may increase the size of the heap to reduce GC frequency, even though the survivors always fit in the previous, smaller heap.  There are many other issues that you can read about elsewhere on GC design.

Your logs show that the GC is operating fairly conservatively with respect to heapsize, preferring more collections to more memory usage, so you are not likely to benefit much from munmap.

Stephen Compall <S11001001>
Group Member
Tue 26 Jun 2007 07:54:26 AM UTC, comment #5: 

I've also tried setting the option --without-libgc which causes immediate Out Of Memory exceptions, so it appears to be picking up the options.

Nick Lee <nick_lee>
Mon 25 Jun 2007 03:20:03 PM UTC, comment #4: 

That doesn't seem to make any difference.  If it's any help, when I turn the GC debugging on in Portable .NET every collection prints out a line similar to the following:

Collection 4 reclaimed 0 bytes
Collection 4 finished ---> heapsize = 1413120 bytes

(where heapsize never gets smaller)

Nick Lee <nick_lee>
Mon 25 Jun 2007 01:37:32 PM UTC, comment #3: 

Try enabling munmap when configuring pnet with ./configure --enable-munmap

But only if mmap is supported on your system.

This will enable returning unused memory to the OS in libgc.

Klaus Treichel <ktreichel>
Group administrator
Mon 25 Jun 2007 01:16:13 PM UTC, comment #2: 

It also doesn't seem to collect on the embedded system we're running on - see new file attached GCTest3embedded.log.

(file #13162)

Nick Lee <nick_lee>
Mon 25 Jun 2007 11:19:02 AM UTC, comment #1: 

With GC Debug on I get the following output:

Increasing heap size by 65536 after 0 allocated bytes
Initiating full world-stop collection 1 after 0 allocd bytes
--> Marking for collection 1 after 0 allocd bytes + 0 wasted bytes
Collection 0 finished ---> heapsize = 65536 bytes
World-stopped marking took 0 msecs
Complete collection took 0 msecs
Increasing heap size by 65536 after 43360 allocated bytes
Grew fo table to 1 entries
Increasing heap size by 65536 after 59956 allocated bytes
Grew fo table to 2 entries
Grew fo table to 4 entries
Increasing heap size by 69632 after 89504 allocated bytes
Increasing heap size by 90112 after 160560 allocated bytes
Initiating full world-stop collection 2 after 245368 allocd bytes
--> Marking for collection 2 after 245368 allocd bytes + 21752 wasted bytes
Collection 1 finished ---> heapsize = 356352 bytes
World-stopped marking took 0 msecs
Complete collection took 0 msecs
Grew fo table to 8 entries
Bytes used: 131072
Forcing GC...
Initiating full world-stop collection 3 after 25048 allocd bytes
--> Marking for collection 3 after 25048 allocd bytes + 12224 wasted bytes
Collection 2 finished ---> heapsize = 356352 bytes
World-stopped marking took 0 msecs
Complete collection took 0 msecs
Bytes used: 356352
Allocating some memory...
Increasing heap size by 1171456 after 696 allocated bytes
Bytes used: 1527808
Removing all references to allocated memory...
Bytes used: 1527808
Forcing GC...
Initiating full world-stop collection 4 after 1050456 allocd bytes
--> Marking for collection 4 after 1050456 allocd bytes + 4080 wasted bytes
Collection 3 finished ---> heapsize = 1527808 bytes
World-stopped marking took 0 msecs
Complete collection took 0 msecs
Bytes used: 1527808
Initiating full world-stop collection 5 after 584 allocd bytes
--> Marking for collection 5 after 584 allocd bytes + 0 wasted bytes
Collection 4 finished ---> heapsize = 1527808 bytes
World-stopped marking took 0 msecs
Complete collection took 0 msecs
Initiating full world-stop collection 6 after 43144 allocd bytes
--> Marking for collection 6 after 43144 allocd bytes + 6136 wasted bytes
Collection 5 finished ---> heapsize = 1527808 bytes
World-stopped marking took 0 msecs
Complete collection took 0 msecs


(file #13160)

Nick Lee <nick_lee>
Mon 25 Jun 2007 10:54:19 AM UTC, original submission:  

In the attached code, the Garbage collector never reclaims any memory when run on Linux.  Program output is as follows:[[BR]][[BR]]
Bytes used: 131072[[BR]]
Forcing GC...[[BR]]
Bytes used: 356352[[BR]]
Allocating some memory...[[BR]]
Bytes used: 1527808[[BR]]
Removing all references to allocated memory...[[BR]]
Bytes used: 1527808[[BR]]
Forcing GC...[[BR]]
Bytes used: 1527808[[BR]]

Nick Lee <nick_lee>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #13162:  GCTest3embedded.log added by nick_lee (4KiB - application/octet-stream)
file #13160:  GCTest2.log added by nick_lee (2KiB - application/octet-stream)
file #13157:  GCTest.cs added by nick_lee (749B - text/plain)
file #13158:  GCTest.log added by nick_lee (475B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by karl (Updated the item)
  • -email is unavailable- added by S11001001 (Posted a comment)
  • -email is unavailable- added by ktreichel (Posted a comment)
  • -email is unavailable- added by nick_lee (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-05-07 karl Discussion LockNone Locked
    2007-06-25 nick_lee Attached File- Added GCTest3embedded.log, #13162
    2007-06-25 nick_lee Attached File- Added GCTest2.log, #13160
    2007-06-25 nick_lee Attached File- Added GCTest.cs, #13157
        Attached File- Added GCTest.log, #13158

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code