Out Of Memory Error

I wonder if my code is just too long or if it is a runtime problem!?

I am in the process of testing my watch (device) app on various watches in the simulator. It turns out that some give an "Out of Memory Error" (see below).

For example, "Fenix 6 / 6 Solor / 6 Dual Power" invokes this error, but "Fenix 6 Pro / 6 Sapphire / 6 Pro Solar ..." does not. For the former it shows "109.5 / 124.0 kB" when showing the error screen. For the latter (Pro version), it says "143.3 / 1275.6 kB".

Unfortunately, I do not understand the "Active Memory" table. If I add up all items shown there, it is far below 143 kB and if I consider the ones in parentheses, it is well above 143 kB.

Error: Out Of Memory Error
Details: Failed invoking <symbol>
Stack:
- initialize() at D:\grmn\prj\di\ciq\toolchain\mbsimulator\submodules\technology\monkeybrains\virtual-machine\api\WatchUi.mb:5352 0x30005111
- onLayout() at ...XXX...\View.mc:124 0x10002992

0 jim_m_58 over 4 years ago

Devices with maps/music allow for much larger device apps (1275kb here). That's the case for devices like the f6 pro devices. On the f6 non pro devices. your max is 124k.

The numbers you see in the bottom line in the sim are what memory is used when the app is idle as well as the max for that device, and there can be peaks. Look at "view memory" in the sim to get more info on memory.

0 Rob over 4 years ago in reply to jim_m_58

The "view memory" is what I meant at the end of my post (it says "Active Memory" at the top of the window). In fact, if I add up everything including the children size, this would be ~250kB!?

0 jim_m_58 over 4 years ago in reply to Rob

Mainly look at the top part in view memory Usage and Peak.

The end result is you need to be at or under 124k to run on a non-pro f6, but you won't see where you're at with a non-pro device in the sim as you ran out of memory, so use a pro device to see where it's at. Looks like you are at about 143k, and you need to trim that by 20k or more to work on a non-pro device.

0 Rob over 4 years ago in reply to jim_m_58

The table shown in the bottom part in view memory does not reflect the "Memory Usage" shown at the top part (or should it? Maybe it only has only a minor influence in my case)

So the memory must be consumed by the code and resources?

0 Rob over 4 years ago in reply to jim_m_58

Btw.: Is there somewhere a table which shows the memory of each Garmin device (at least the watches)?

0 jim_m_58 over 4 years ago in reply to Rob

I believe some things can be seen in different ways in the bottom part. I've not actually looked that closely as the numbers at the top are what matter.

0 jim_m_58 over 4 years ago in reply to jim_m_58

For me at least, using the info at the bottom is helpful when you may want to save a few bytes here and there, but when you're looking at 20k, you need to look at big changes to the code, possibly removing functionality either directly or with jungles. Or simply, don't support the devices with 124k for device apps.

0 Rob over 4 years ago in reply to jim_m_58

That's probably the way.

0 FlowState over 4 years ago in reply to Rob

Rob said:
In fact, if I add up everything including the children size, this would be ~250kB!?

Yeah, it's annoying. It happens when the memory viewer shows you duplicate references to objects. (e.g. if you expand everything, you may see duplicate object #s under the Notes column)

So the problem is that your view and delegate may have references to the same objects (for example), and the memory viewer doesn't have a good way of showing you the total memory taken up by *unique* child objects. Or multiple items in the view stack may have references to the same objects, etc.

Notice that the top level View Stack item doesn't even have a memory summary, probably for this reason.

If anyone actually went to the trouble of expanding the whole thing and adding up all unique objects (and other types), I think the numbers would make sense.

It's too bad it doesn't have an option to show unique objects on the heap, in addition to showing objects organized by "View Stack".

e.g. If it was organized like this, then maybe it could show you a coherent view of your memory without duplicates, I think:

Global

Heap

Code

Data

Entry Point

API Callbacks

API Statics

Timers