.Net object Life cycle\lifetime vs unmanaged code

213 Views Asked by At

I am trying to understand how objects are created in a .Net world as oppose to that in an unmanaged code environment (VB6 etc)

From what I understand, when an object is created in lets say C# by using the new keyowrd, the reference variable is placed in the managed heap until the garbage collector takes a proactive measure to check if the object still have references to it. If not, it is destroyed. Does this mean the GC is always running? Isnt this an expensive process?

Can someone explain better?

How does this differ in an umnanaged code environemnt?

1

There are 1 best solutions below

0
Cylon Cat On

GC does not run continuously. It runs on demand, which means that a memory request can't be filled without first releasing some memory. So no, it isn't a huge expense. In server side, it can run in background. (I seem to remember that this will be expanding, with more multicore systems available now?)

For most applications, GC is a huge improvement over unmanaged code. There's no reference counting, and no need to track all the paths where an object might need to be released. When it's no longer referenced anywhere, it becomes collectable. This greatly simplifies coding, and memory leaks are nearly (not completely) a thing of the past.