[Ovmsdev] Memory leak

[Stephen Casner]

We've been dancing around the external RAM allocation decision with
our own ExtenalRamMalloc() function and extensions to the C++ new
allocator to try SPIRAM first but then back off to internal memory if
that fails (presumably because of v3.0 hardware rather than because
all 4MB of SPIRAM is used up).

Do we need all that?  There is already a mechanism in the multi-heap
memory system for the defaut malloc to try allocating from SPIRAM for
any request with size larger than malloc_alwaysinternal_limit which
can be set dynamically with heap_caps_malloc_extmem_enable().  If the
allocation from SPIRAM fails (again, presumably only on v3.0 hardware)
then the allocation is retried without the MALLOC_CAP_SPIRAM
capability, which is just what our ExternalRamMalloc does.

If there are only a few allocations such as stacks that must come from
internal memory, and if those allocations (in system code) already use
heap_caps_malloc(MALLOC_CAP_INTERNAL) to meet that requirement, then
we could probably just set malloc_alwaysinternal_limit to a small
number (perhaps 0) so that everything else comes from SPIRAM.

I don't know if any of our application memory uses are sufficiently
sensitive to memory performance that we would want to ensure that the
memory is internal.  My guess is that those would be few and therefore
it makes sense to take special action for them rather than for
everything else.

For continued support of v3.0 hardware we could even test whether
SPIRAM is present and leave malloc_alwaysinternal_limit at its default
value of -1 if not.

Opinions?

                                                        -- Steve

On Mon, 23 Apr 2018, Mark Webb-Johnson wrote:

> Michael,
>
> Do we need ovms_extram.h? Can we just put the namespace directly
> into ovms.h (where all the other external ram allocation stuff is)?
>
> Regards, Mark