Totally unrelated. You are creating 100 megs of objects for the list. the GC won't delete it because the objects are still referenced within the list. Each object is at least 4 bytes, plus each link in the list is going to need at least 12 bytes. So you are trying to allocate at least 1.5 GIGS of memory to hold the list! Most computers do not have that kind of memory, if they do, Windows most definately wont leave that much for a program. When memory fills up, everything gets shoved to virtual memory and everything comes to a crawl.
If you notice, the bug that we're talking about happens even when nothing is being allocated. You can keep an eye on the memory in the task manager and see that memory usage does not increase over time.
Edit: I just reread your post and noticed that you said that negatives are not a problem, but I thought I'd leave this in because I feel it's still relavent.
As for rate becoming negative, this is not from an overflow problem. It's from such a huge amount of memory finally being freed that rate+=500-gc_objsfreed will actually return a negative value and is expected behavior.
Notice these two lines
notice how 512371 objects are being freed? Now do the math. 22364 + 500 - 512371 = -489507 which is the rate in the next line. Also notice that the values get nowhere close to being in overflow range which is 2147483648. As for the slight delay when the objects are freed, that's to be expected. It takes time for the GC to do it's job, and the more garbage it needs to clean up, the more time it will take. You are freeing 512371 objects, 10 megs of memory. The GC must scan each object individually and see if it's being referenced anywhere in your program, then free it from memory. Reminds me of the C64 days when BASIC programs would seem to freeze for half a minute while it's GC did it's job.
Now I'm not saying that it isn't a GC related problem. I don't have a clue, but it obviously has nothing to do with rate overflowing, nor with the example you are showing which is being caused by more memory being allocated than Windows can handle.
If you notice, the bug that we're talking about happens even when nothing is being allocated. You can keep an eye on the memory in the task manager and see that memory usage does not increase over time.
Edit: I just reread your post and noticed that you said that negatives are not a problem, but I thought I'd leave this in because I feel it's still relavent.
As for rate becoming negative, this is not from an overflow problem. It's from such a huge amount of memory finally being freed that rate+=500-gc_objsfreed will actually return a negative value and is expected behavior.
Notice these two lines
GC collectMem: memFreed=10212300, time=223ms, objsFreed=512371, rate=22364, objsScanned=54, objsLive=15 GC collectMem: memFreed=0, time=0ms, objsFreed=0, rate=-489507, objsScanned=54, objsLive=15
notice how 512371 objects are being freed? Now do the math. 22364 + 500 - 512371 = -489507 which is the rate in the next line. Also notice that the values get nowhere close to being in overflow range which is 2147483648. As for the slight delay when the objects are freed, that's to be expected. It takes time for the GC to do it's job, and the more garbage it needs to clean up, the more time it will take. You are freeing 512371 objects, 10 megs of memory. The GC must scan each object individually and see if it's being referenced anywhere in your program, then free it from memory. Reminds me of the C64 days when BASIC programs would seem to freeze for half a minute while it's GC did it's job.
Now I'm not saying that it isn't a GC related problem. I don't have a clue, but it obviously has nothing to do with rate overflowing, nor with the example you are showing which is being caused by more memory being allocated than Windows can handle.