Garbage Collectionin .NET

[Rimonne]

Hi All

I understand that the .net framework has garbagecollectors which run
automatically and release memory.

But in my application in C#, i have an object which should never be
released.

Can I achieve this in .NET ?

An urgent response is neede, as I am struck up with my development work
here.

Thanks a lot for your time.

Regards.

 

[Randy A. Ynchausti]

Rimonne,

But in my application in C#, i have an object which should never be
released.

Can I achieve this in .NET ?

All you have to do is make sure your application has a reference to the
object. Therefore, it will never be released.

Regards,

Randy

 

[Rimonne]

Cant i use
GC.SuppressFinalize method for this? Just read it in msdn.

 

[Mattias Sjögren]

Cant i use
GC.SuppressFinalize method for this? Just read it in msdn.

No, GC.SuppressFInalize just prevents the Finalize method from being
called (good for performance) once the object is collected.

As Randy said, keep a live reference to the object.



Mattias

 

[Ed Kaim [MSFT]]

That isn't necessary. As long as your object is referenced, it won't be
garbage collected. After all, if your object isn't referenced somehow, then
you wouldn't be able to access it anyway. The article at
http://msdn.microsoft.com/msdnmag/issues/1200/gci2/default.aspx gives an
overview of garbage collection in the .NET Framework.

 

[Morten Wennevik]

..NET keeps track of your objects through a set of reference tables.

Every now and then (you have no control of when, though you can attempt to
force it using System.GC.Collect()) the garbage collector will go through
these tables and flag objects your program has no references to anymore.
It will then unravel these objects (which may have references of its own)
and release it from memory.
After that it will rearrange your objects to tidy up the use of memory
(allocating memory under .NET is actually faster than in native C).

However, since you have no control of when it runs, time and performance
critical applications may find that the garbage collector may run at a
time you really don't want it to. In that case, you can turn it off
alltogether and handle all memory by yourself.

Another limitation is using resources, like file handlers and database
connections, of which it isn't very good at cleaning up itself. So any
object that has a Close() method you should call Close() on when you are
finished using it.

PS! To release an object simply set the reference to null. The object
will float into the unknown, waiting to be eaten by the garbage collector.

 

[Morten Wennevik]

That isn't necessary. As long as your object is referenced, it won't be
garbage collected. After all, if your object isn't referenced somehow,
then you wouldn't be able to access it anyway.

Actually, you can. You can write code in the object that refreshes it's
reference when it is about to be collected. I can't think of any reason
to do that, but you can.

 

[Milica Bogovac]

I understand that the .net framework has garbagecollectors which run
automatically and release memory.

But in my application in C#, i have an object which should never be
released.

Can I achieve this in .NET ?

I think that:

Object.Dispose();

should do it.

Regards, Milica

 

[Manoj G [MVP]]

Oops! That is something we are trying not to do. If Dispose is called on
the object, you are infact telling that the resources held by object be
released (and hence no finalization be required).
As some folks already said, in order to achieve what you trying, I guess you
can keep the reference of the object somewhere alive. This can be a static
member of class and you make sure that you do not set the this to
null/nothing in your code. This object's gonna be there till the appdomain
in which this object exists unloads.

 

[Glen Jones MCSD]

Hello,

I suggest creating a "C# static" variable to keep the referance.

Hope this helps.

 

[Jay B. Harlow [MVP - Outlook]]

Rimonne,
Have you considered implementing the Singleton Pattern? (or a variation
there of).

http://www.yoda.arachsys.com/csharp/singleton.html

Hope this helps
Jay

 

[Max-Ph. Blickenstorfer]

Hi Rimone,
After reading the various replies you've got so far. My reply would be best
described in this article:
http://msdn.microsoft.com/msdnmag/issues/03/12/leasemanager/default.aspx

Acording to above article it is not enought to hold a reference to the
object, the object must recognize some activity. To make sure the connection
will not be marked for garbage collection you have to work with "Leases".
For each created object the framework creates a lease. This lease is managed
by the frameoworks lease manager. By default an object is marked as inactive
after 5 minutes inactivity. However, you can manipulate the lease behaving
and create a callback interface on your clients side. This callback function
will be called by the lease manager and your client can specify whether the
server side object can be disposed or not. In fact it would be good your
client side object implements IDispose, so your client can release resources
when you feel it's appropriate for it.

Another good article covering remoting objects is in CodeMagazine Jan/Feb
2003. Even nearli a year old - it contains quite a bit content.
http://www.code-magazine.com/

Anyway, I hope the above linkes can bring some light into this behaving.

Regards
Max

 

[Daniel O'Connell]

This article applies to remoted objects, not to local objects. A local
object does not require activity to remain in existance.

 

[Max-Ph. Blickenstorfer]

Hi Daniel,
You're right - my head currently sticks in remoting objects to .net and mfc
clients and of course lifetime/validity of those objects.

Thanks for the justification.

Regards
Max