Memory usage with different SDK's

Hi all together, perhaps you can help
Im running in out of memory with my watchface with latest SDK 3.0.3
Many settings are implemented and the peak memory on settings changed is becoming more and more with every SDK Version.

I have check this with the same operation (change the same settings) and different SDK's with follow results:

SDK 2.4.9
Memory Usage: 79.4/92.1kB
Peak Memory: 85.5kB
Object Usage: 157/65535
Peak Objects: 290

SDK 3.0.1
Memory Usage: 79.8/92.1kB
Peak Memory: 86.0kB
Object Usage: 159/65535
Peak Objects: 292

SDK 3.0.3
Memory Usage: 79.9/92.1kB
Peak Memory: 91.1kB
Object Usage: 160/65535
Peak Objects: 366

I can't migrate to SDK 3.0.3 without reducing the functionality.
But why does the Peak memory increase so much with latest SDK.
community.garmin.com/.../1404817.png community.garmin.com/.../1404818.png community.garmin.com/.../1404819.png
  • There is really no substantive documentation on the internals of the VM, but you can infer some of the details through experimentation and testing.

    At a high level, the VM has both a stack and a heap. Primitive object types (Lang.Char, Boolean, Number, Float, and object references) are stored directly on the stack. Everything else (Lang.Long, Double, Array, Dictionary, String, ByteArray, and all other user defined types) is stored on the heap. Basically, if the data representation is no larger than that of an object reference, we store the data directly in the reference itself.

    If you have a specific question, feel free to ask.
  • In general, heap means the memory heap - the available memory, over all. The heap is memory management.

    Stack usually means program stack. What function called what function from where, so when the second function completes, it knows where to go back to in the calling function. See the stack trace in a ciq_log file. The program's stack shows you where the problem occured, and who called that function from where. The stack is also used to pass the parameters from the calling function to the called function.

    And in some cases, the program stack is allocated from the heap!
  • If you have a specific question, feel free to ask.

    I would very much like to know more about the workings of the VM, and thank you for your invitation to ask questions.
    Could I start off by asking for a high level diagram of the components?
    I have borrowed from the structure of the Java VM as a model : [TABLE="border: 1, cellpadding: 1, width: 500"]
    [TR]
    [TD]Java[/TD]
    [TD]Garmin[/TD]
    [/TR]
    [TR]
    [TD]Java Byte code[/TD]
    [TD]Monkey C byte code[/TD]
    [/TR]
    [TR]
    [TD]JVM[/TD]
    [TD]CIQ VM[/TD]
    [/TR]
    [TR]
    [TD]Applications[/TD]
    [TD]What other applications at this level[/TD]
    [/TR]
    [TR]
    [TD]OS[/TD]
    [TD]Garmin RTOS[/TD]
    [/TR]
    [TR]
    [TD]Real Machine[/TD]
    [TD]ARM Cortex-M[/TD]
    [/TR]
    [/TABLE]
    And wonder how close it is to a CIQ 3 device.
    I would have liked to embed some diagrams, but sadly they become miniaturised and unreadable:(
  • Could I start off by asking for a high level diagram of the components?

    That is not a specific question. I'm offering to answer specific questions that might help you to write smaller or more efficient code, not to describe every facet of the software stack. I'm not sure how a block diagram of the essential components helps...

    And wonder how close it is to a CIQ 3 device.

    Yes, this is pretty much what the ConnectIQ stack looks like.