Garbage collector

[septic]

I have 2 questions about the garbage collector

1. When I compile the program I see : … GC 4ms …
   Is this indication is the rate of GC ? every 4ms ?

2. When I have an interrupt, and, in the same time, the Garbage begin his work.
   Which code is excecuted ? My interrupt or the garbage collector ?

[Ravenheart_Toshko]

1. It means the GC took 4ms to do its job, NOT how often it will fire.
2. The GC will do its job and then fire your interrupt, you can use the timestamp to check exactly when the interrupt happened.

[Gus_Issa]

The GC will not just fire randomly. If your interrupt doesn’t allocate objects then GC will never fire. Actually, you may write your entire project in a way where GC will almost never need to fire…but this may over complicate your code.

[septic]

Well,

So I need more explanations about thr GC.
You see the beginning of the interrupt for the serial port ;

        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        private void UART_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            // Check if Chars are received
            if (e.EventType == SerialData.Chars)
            {
                // Create new buffer
                byte[] rx_data = new byte[UART.BytesToRead];
                // Read bytes from buffer
                UART.Read(rx_data, 0, rx_data.Length);
...

Is it the GC will fire with this code ?
If yes, have you a example to force the CG that not fire in my interrupt ?

[Silic0re]

The GC fires when there is garbage to collect. If you don’t create garbage, it won’t collect anything. You can use a pre-allocated buffer for your serial input instead of creating one in the interrupt for beginners.

BTW, it won’t fire every time, it will fire when it determines that there are enough dead references to memory that it needs to clean up. Your other code can have just as much as an effect on this as your interrupt code.

[Gus_Issa]

byte rx_data = new byte[UART.BytesToRead];

This is bad as you are allocating memory inside your interrupt…which can trigger the GC. Not only that, the object is discarded when interrupt is done (free memory)…this means, a 1000 interrupts/sec will give 1000 object begin allocated and freed every second!

[septic]

Hoho I learn…

Ok I try to resume

It’s not a good idea to create an object in the interrupts methods.
If I has understand correctly, when an object is not used for a time ( x ms ?) the GC fire this object. In the case of the interrupt the CG use his time plus the time of the interrupt. (not really efficient !)
I will change the RS232 interrupt with create a buffer that memorize the received characters. Perhaps have you an example ?

My question is perhaps not really intelligent, but I suppose the CG clear the unused variables too ?
In this case what’s the difference in memory between an object and a unused variables ?

Thank you for your help.

[Silic0re]

If you have unused variables the compiler will get rid of them…

The GC is really a reference counter more than a time one. If you don’t have any more references to an object you created, the GC will clean it up. For example, if you create an array in a function then exit the function (without returning the array as a value), then the references to the array become zero and the GC marks it for clean up. That doesn’t mean its going to happen right away, but it will happen eventually.

The way to get around the GC is to create and allocate your objects globally when you start your program. Then you have to minimize the number of times you create new objects (type = new type) and variables. Creating objects in functions that are called often or quickly will incur a lot of GC overhead, since the GC needs to clean up whatever you don’t. This is analogous to the old c/c++ where if you created something with malloc or new, you needed to release it with free or delete (otherwise you had a memory leak). The difference here is you are letting the GC take care of destroying the object.

[WouterH]

I was wondering if a struct must be garbage collected? I asume not since they should appear on stack?
Can anyone verify this?

(This would mean you can safely use structs in functions that are called often)

[Silic0re]

You are still creating a memory object, which is managed by the memory manager. Since the stack isn’t much more than a bunch of pointers (most structs can’t fit on the stack), it’s still a memory object. These are placed in the generation management system and garbage collected like any other object.

Here is a good reference of how the garbage collector works:

Garbage Collector Basics and Performance Hints

[WouterH]

Thanks Ron2 for the clarification.

[demonGeek]

From a purely theoretical perspective it’s worth noting that the NETMF garbage collector is not implemented in quite the same way as the full framework garbage collector.

This document has more details: http://download.microsoft.com/download/a/9/c/a9cb2192-8429-474a-aa56-534fffb5f0f1/.net%20micro%20framework%20white%20paper.doc

From page 20 of that document:

The approach to garbage collection used in .NET Micro Framework CLR differs from the automatic memory management provided by the full .NET CLR in several respects. Instead of a generational garbage collector, the .NET Micro Framework CLR uses a non-incremental mark-and-sweep algorithm. This simpler approach was chosen due to the limited availability of RAM in small devices. More sophisticated approaches were explored, but the tradeoffs required made them impractical.