Hi,

I know that we can force the garbage collector to kick in, although it's not recommended.

Is there anyway to _prevent_ the Garbage Collector to collect certain object?

Thanks

why would you want to do this?

Make sure you have a referance to the object and then it wount be GCed.
The GC looks for orphaned objects ie objects with no referance on the stack so if you still keep a referance on the stack for that object you wount lose it.

Thanks for your reply. But...

Are you saying that in order to prevent GC from collecting the object, I have to have a reference for it on the stack? How do you do this if the object is actually a global object?

Thanks,

It's all to do with scope.
If your object is inside the scope of your program, it's referenced
via the stack and there for woun't be GC-ed.

The GC kicks in on objects with references that have gone out of scope and those whitch have null asigned to them.

A reference lives on the stack and the object lives on the heap.
It's like C, but the memory locations are named now.

Are you having problems with your code?

I have a main process that enqueue objects onto a Queue. When it is necessary, I queue the object. Otherwise, my main process does something else. I also have another thread that dequeues the object from the Queue, and process it.

When the Queue is empty, it takes a while to generate the Queue. I timed this. When I enqueue the second object, it takes shorter time than when I enqueue the first object.

When I dequeue the object, I have no problem. I can dequeue them one by one. However, after I dequeue the last object, the enqueueing of the next object (becomes the only object) takes a long time, comparable to when I enqueue the first object.

So I suspect that when the Queue is empty, the GC kicks in.

You talk about scope. Where is the boundary? If I spend most of my time in the main process, and once in a while call a function that enqueue the object, and the dequeueing is done in another thread, is the Queue is still in-scope? When I'm in the main process, is the Queue in-scope?

So the problem I'm having is the long time it takes to Queue an object that would become the first one in the Queue.

Thanks,

The GC runs on what we call a Daemon thread.
In layman this means a low priority thread. Two or three priority, Five is default.

This means that all level five priority threads will have priority over Daemon threads.

I dont think your problem is with The GC taking up CPU.
It could just be cause of the initial load up of the dll. Read up a bit about Queuing if you feel that the speed is a problem.

It's not the GC process taking up the CPU and hence slow down the execution.

I could be wrong, and I don't want to sound pushy, but is there a chance that when the Queue is empty, the GC kicks in, and hence the next time I enqueue object, the code must (like you said) load the dll, etc?

If that is the case, is there a way to tell the GC _not_ to collect the Queue object, even when it is empty (I assume when it is empty it is considered as not referenced, and hence it can be GC'd)

My problem is with the Queue creation taking time.

Thanks for answering.

: Hi,
:
: I know that we can force the garbage collector to kick in, although it's not recommended.
:
: Is there anyway to _prevent_ the Garbage Collector to collect certain object?
:
: Thanks
:

I'm not sure if this is what you want but it is possible to stop the GC from calling the 'Finalize' method on an object and then later on you can tell the GC that the 'Finalize' can be run so that the object is destroyed.

//Tells the GC not to call the finalize method of an object
GC.SuppressFinalize()

//Tells the GC that it can now call the finalize method on the object.
GC.ReRegisterForFinalize()

rai_net