N18 SimpleGraphics memory usage / GC

Hi

I’m having a problem where my application stops receiving interrupts from an extender module. It seems to always be after the garbage collector has run. If i do a number of updates on the display, the GC always run. Curious on both why the interrupts stop, and why the collector runs so often when updating the display. Perhaps this is normal?

The following code:


void ProgramStarted()
    {
      Debug.Print("Program Started");
    
      int i = 0;
      
      Font smallFont = Resources.GetFont(Resources.FontResources.NinaB);

      while (i<100)
      {
        i++;
        display_N18.SimpleGraphics.Clear();
        display_N18.SimpleGraphics.DisplayText("Testprint"+i.ToString(),smallFont,Color.White,5,5);
        Debug.Print("Printed nr:"+i);
      }

      Debug.Print("Program Ended..");
    } 

will generate the output:
(…cut the beginning and end from output…)

Printed nr:24
Printed nr:25
GC: 3msec 559716 bytes used, 6779952 bytes available
Type 0F (STRING ): 552 bytes
Type 11 (CLASS ): 9084 bytes
Type 12 (VALUETYPE ): 1068 bytes
Type 13 (SZARRAY ): 43956 bytes
Type 03 (U1 ): 41160 bytes
Type 04 (CHAR ): 636 bytes
Type 06 (U2 ): 24 bytes
Type 07 (I4 ): 756 bytes
Type 0F (STRING ): 48 bytes
Type 11 (CLASS ): 1332 bytes
Type 15 (FREEBLOCK ): 6779952 bytes
Type 16 (CACHEDBLOCK ): 24 bytes
Type 17 (ASSEMBLY ): 27444 bytes
Type 18 (WEAKCLASS ): 96 bytes
Type 19 (REFLECTION ): 192 bytes
Type 1B (DELEGATE_HEAD ): 360 bytes
Type 1D (OBJECT_TO_EVENT ): 264 bytes
Type 1E (BINARY_BLOB_HEAD ): 470208 bytes
Type 1F (THREAD ): 768 bytes
Type 20 (SUBTHREAD ): 96 bytes
Type 21 (STACK_FRAME ): 1968 bytes
Type 27 (FINALIZER_HEAD ): 192 bytes
Type 28 (MEMORY_STREAM_HEAD ): 36 bytes
Type 29 (MEMORY_STREAM_DATA ): 396 bytes
Type 31 (IO_PORT ): 252 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 2688 bytes
Printed nr:26

Before reaching 100 the GC runs 3 times. The program and display updates continue to run to completion.

Regards
/John

@ John Karbin - In your loop you are creating strings and then orphaning them each iteration, this is the result of the concatenations. Then you can take a look at the module driver, there might be some additional allocations going on in there, test by changing your code to not create the strings every iteration.

You are also running a loop within ProgramStarted. It’s not recommended to do anything in here that will take time. That can mess up timing and may be your issue.

Better you spawn a thread to do any processing.

interrupts are not dispatched until you leave the ProgramStarted method.

but nothing in the posted code would cause an interrupt?

I did forget to respond to the part about the interrupts stopping after the GC. It sounds like the code is not maintaining a reference to an InterruptPort instance and when the GC occurs the interrupts stop, all speculation of course until we see that specific code.

@ taylorza - It seems that the allocation is done inside the Display method. I moved the allocation outside, and ran the display with the same string. That had no effect on how often the GC is called.

@ taylorza - The reference was the problem. I had unintentionally allocated the interrupt port in an init method, and had no reference in the class. So that solved the problem.

@ Mike - The code I posted was just to point to how often the GC was called when using the display.

Thank you guys for pointing me in the right direction! :slight_smile: