I'd like to check how much memory I have available for my program.
I tried maFreeObjectMemory() / maTotalObjectMemory(), but they both return INT_MAX both on emulator and on my Sony Ericsson C702.
Am I doing something wrong or these functions are not yet fully implemented?
I'm using MoSync 2.3B r767.
These functions are disabled on the emulator, but they should work on all phones. We'll see if we can reproduce the error.
By the way, why are they disabled on the emulator?
As far as I understand, the heap size available to the program is explicitly specified in Build Settings, and verifying that the program is capable to work in the specified memory limits is a good idea. So why not make those functions available to the emulator?
I've just tried a test program using maFreeObjectMemory(); and maTotalObjectMemory(); on a W995 and get what seem to be realistic values (53920 and 10488576). I'll see if I can try this on a C902.
Heap memory and object memory are different things.
A MoSync runtime is a virtual machine, which has allocated a fixed amount of RAM. (This is "data size" in Build Settings.) The heap (used by malloc()), the stack and static data all share this RAM.
MoSync objects, on the other hand, are allocated outside the virtual machine, using various platform-native methods. MoSync objects come in different types, such as images, sounds and data buffers. ma*ObjectMemory() reports on the memory used by these objects.
These functions should be available on the emulator too, but if they are to mirror the conditions found on real devices, we would need accurate data on the memory characteristics of each device, and we currently don't have enough of that. Also, it would have to be integrated and tested, which would take a bunch of work-time. I'm afraid it's fairly low on our priority list at the moment.
Hmm, it seems I deployed the program somehow incorrectly. An old deployment showed INT_MAX/INT_MAX, but now when I redeployed, it shows the correct values similar to the ones you provided.
Sorry for the mess, I can't find out what has changed. I'll try a bit more, if I find what was the older configuration that caused INT_MAX to be returned on the phone, I'll post here. For now it's "Can't reproduce", sorry.
Fredrik
Thank you very much for the clarification!
Is there a way to find out the amount of available _heap_ memory?
My program is going to use a rather lot of heap dynamically, and I'd like to have an estimate of how big the program really is at the moment and, therefore, how much it can still grow.
Thank you!
Is there a way to find out the amount of available _heap_ memory?
We should definitely have such a function, but currently we do not.
If you don't want to wait, you may implement override_heap_init_crt0() to set it up yourself. In it, I would call the current initialization function, ansi_heap_init_crt0(), and also save the heap base pointer, for use with get_used_size(), which should tell you how much heap memory has been used.
See maheap.h, maheap.c and tlsf.h in our source code for additional details.
Whoa, sounds great!
Tried that:
#include <maheap.h>
#include <tlsf.h>
void* heapStart;
void override_heap_init_crt0(char* start, int length) {
heapStart = start;
ansi_heap_init_crt0(start, length);
}
size_t freeHeapMemory() {
return get_max_size(heapStart) - get_used_size(heapStart);
}
size_t totalHeapMemory() {
return get_max_size(heapStart);
}
lprintfln("%d %d", freeHeapMemory(), totalHeapMemory());But the result is stable:
0 0
It seems that's because TLSF_STATISTIC is not set in tlsf.c
Is it a sentence or there's still something I could do? 
I agree about TLSF_STATISTIC. We should set it.
At this point, you'd have to recompile the entire MAStd library. 
I'll make the changes on our end, so that they'll be available in the next nightly build.
Oh, I see. Will wait for the nightly.
By the way, maybe it's good idea to rename those freeHeapMemory/totalHeapMemory into maFreeHeapMemory/maTotalHeapMemory and put them into maapi.h?
By the way, maybe it's good idea to rename those freeHeapMemory/totalHeapMemory into maFreeHeapMemory/maTotalHeapMemory and put them into maapi.h?
No, the 'ma' prefix is reserved for syscalls.