Capacity of MC on VA-HR

I wonder if the object use/free could be something happening "under the hood" in the VM. A timer tick, a request for onUpdate() from the VM, a new call to something like onPosition(), etc.

Pretty scary if it is. That would be a show stopper for me. I'm only 5% into the code migration and already at 80% of the object count limit.

Real case. I have an app, with 11 different screens, records data, and it uses an array that can store 14 hours of minutely GPS data. And I don't worry about the object count.

I have to say I'm not at all comfortable with the thought of walking into the forest blindfolded. I'll be interested a second opinion from Travis.

I'll look at the code in the morning.

Travis

I'll look at the code in the morning.

Travis

Thanks, I'm in Sydney UTC +11

I'm not sure how, but it seems like my post from Sunday didn't take... I took a ton of notes in there, and I have no copies... So, from memory...

It seems that the object limit is imposed for classes allocated with new and for the larger built-in types (Lang.Array, Lang.Dictionary, Lang.String, Lang.Double, and Lang.Long). I did a bunch of testing with Lang.Float and Lang.Number and you can create as many of these as you want (up to the memory limits of the device) without problems, provided you don't allocate them with new. I was able to create something like 23000 Lang.Number instances without running into any problems on the simulated fr735xt (which has 122K application memory).

As mentioned above, the object id numbers are definitely recycled. They appear to be cached in a last-in-first-out fashion (a stack). This makes it possible to do some testing with object counts, if you allocate and deallocate all of the objects in the appropriate order in your function. It won't work well if you hold references to some objects and release references to others. Unfortunately, there just isn't a way to get information about the current object count once you start allocating and deallocating objects out of order.

All that said, I'm with Jim. I'd just try writing you app.

Travis

Travis has hit most of the important details.

As you've discovered, there isn't really a way to track your number of allocations. I'll see if I can convince anyone to get this exposed.

You should be generally safe if you avoid using large numbers of "small" objects. Regular class objects should run you out of memory before you run out of handles in most cases. "small" objects include Strings, small Arrays, small Dictionaries, Longs, and Doubles. Most everything else should hit your memory limit harder than your object limit.

So, from an object count limit perspective it would appear that there are (at least) two "classes" of objects, those that are counted and those that are not. If Travis can generate 23000 Lang.Number instances, then it's apparent that the 509 limit doesn't apply to them.

"small" objects include Strings, small Arrays, small Dictionaries, Longs, and Doubles.

And Brian refers to "small" objects, which begs the question: what are small and what are not (and why?).

I should have explained a bit more probably. There are a handful of types that, as Travis has pointed out, do not take an object allocation. At a technical level, these are objects that are (always) 4 bytes or smaller. Specifically you will find that Number, Float, Boolean, Char, and null objects do not require an allocation.

By "small" objects I am referring to objects that do require an allocation, but take up a very small amount of memory. Longs and Doubles are perfect examples as they use an object allocation, but that allocation is only 8 bytes. If define a class and instantiate it, this also takes up an object allocation, but it is much larger. These types of allocations take a larger percentage of your memory pool than your available objects.

In most applications our expectation is that you should not run out of allocations before you run out of memory, but using a large amount of strings, or long/double values can use up the allocations quickly.