Enhanced GDI disposal in NET?

[vbnewt]

I've been doing way too much reading lately on the Dispose issue, and particularly pondering the best way to handle fonts, bitmaps, etc. in the context of WinForms controls.

Some of my messing around has seemed to indicate that NET may currently be doing a better job of disposing GDI objects (without my code implementing/calling Dispose) than my reading (including a lot of MSDN articles) has led me to expect.

For example...

Public Class FiveBitmaps

    Public Property bmp1 As Bitmap
    Public Property bmp2 As Bitmap
    Public Property bmp3 As Bitmap
    Public Property bmp4 As Bitmap
    Public Property bmp5 As Bitmap

    Public Sub New()
        bmp1 = New Bitmap("D:\P\One.bmp")
        bmp2 = New Bitmap("D:\P\Two.bmp")
        bmp3 = New Bitmap("D:\P\Three.bmp")
        bmp4 = New Bitmap("D:\P\Four.bmp")
        bmp5 = New Bitmap("D:\P\Five.bmp")
    End Sub

End Class

Public Sub Test5Bmps()
    Dim f5 As New FiveBitmaps
    MsgBox("Width: " & f5.bmp2.Width)
End Sub

Those bitmaps total around 700 MB, and if I have Task Manager open (Processes tab), I can see that the Memory total for my app jumps around 700 MB from the moment before I run the Test5Bmps sub to the time when the MsgBox is displayed. And the total memory percentage at the top of the column jumps around 9%.

But then... after I click out of the MsgBox, both Memory indicators jump back down to their previous levels (i.e., 700 MB lower) within five seconds or so, notwithstanding a complete absence of Dispose-related code by me.

It's my understanding that the lion's share of that 700 MB of RAM is the pixel data from those bitmaps, and that that data is stored in *unmanaged* memory (not the heap), and I thought that meant that the Garbage Collector wouldn't free up that memory without assistance from an IDisposable implementation by the coder in the class that creates the bitmaps — in the absence of which there'd be a memory leak.

Has there been a recent upgrade to the way NET handles GDI objects, or am I misunderstanding something?

(And yes, I would bet that it's the latter.)

I should also note that if I monitor the Details tab (of Task Manager), I can run Test5Bmps repeatedly with no *cumulative* increase in the number of GDI objects shown there. (That is to say, it goes up and then back down, just like the RAM in the Processes tab.)

And in case it's relevant, I'll add that the WinForms VB project I'm running this code in is targeting NET 4.8.

[PlausiblyDamp]

Presumably the finaliser is getting called and this is freeing up memory. Even though clean up is happening, you should still call dispose, rather than relying on the GC to deal with this.

[Shaggy Hiker]

I'm surprised that the memory goes back down. Why should it? Allocating memory is expensive, releasing memory is more costly than not releasing memory, so why should memory go back down? After all, the program doesn't know that the bitmaps won't be needed again, and holding onto the memory costs nothing at all...until it does. The OS knows how much memory there is, and all requests go through that, one way or another. If application X says, "I want M amount of memory", and the system has M + N memory, then why wouldn't the OS simply give the application the memory it wants? Also, where in that is the mechanism to release the memory? The application knows whether or not it is actively using the memory, but it costs a bit to release it, and releasing it would necessarily mean prioritizing looking for memory to release over other tasks, so why would it happen?

What could happen is that the application sees that nothing is happening, and decide to go looking for memory to release. However, it would require a higher level of understanding for the application to know not just that nothing is happening NOW, but that nothing is going to happen a millisecond in the future. When would it be safe for the application to do something as costly as garbage collection?

This isn't an unsolvable problem, but it's a tricky one that has little benefit to solving. After all, while some programs might well have a time during their life cycle when aggressively releasing memory is a reasonable thing to do, the vast majority of programs will either not have a suitable time, or will not have memory that can be released. Why even both creating such a system that has so few benign uses while having notable costs.

Instead, let the OS monitor memory. If the OS decides that memory is running low, then the OS can tell applications to stop what they are doing and release any memory they can spare. That's the most rational memory management, and I believe it's the one used by Windows. Therefore, I don't see why the memory usage is dropping while your program is running.

[Niya]

@OP

What version of .Net are you using?

[vbnewt]

What version of .Net are you using?

The project I'm running that code in is targeting NET 4.8.