Custom Heap Allocation.

[slaff]

Based on umm_malloc. Most of the integration code comes from esp8266/Arduino.

Advantages:
-- Better heap allocation and less fragmentation. We can use the available free heap more efficiently.

Disadvantages:
-- A bit slower than the original mem_manager functions.

[hreintke]

@slaff :
Due to the status of Sming NONOS being replaced by SmingRTOS I am not in favor of putting this kind of major updates in.
For SmingRTOS the heap assignment is based on the Freertos implementation, not sure how this will fit in but please first align before implementing.

[ADiea]

Hi do you have example output for this function call? I'm curious if this could be used for run time fragmentation monitoring

[slaff]

I am not in favor of putting this kind of major updates in.

@hreintke I can check how is the memory allocation done in RTOS and port the same code also for SmingRTOS.

heap assignment is based on the Freertos implementation, not sure how this will fit in

I will be surprised if it is much different than the one in NONOS. But I have to check. Anyone having an idea about this?

I'm curious if this could be used for run time fragmentation monitoring

@ADiea Because one has control over the memory management functions it is possible to log the memory allocation and should be relatively easy to implement (as done here ).

[slaff]

I will be surprised if it is much different than the one in NONOS. But I have to check. Anyone having an idea about this?

It turns out that the heap allocation is open source and can be read from here:
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/third_party/freertos/heap_4.c .Well, from here on only a good comparison can show the winner: FreeRTOS vs UMM.

[hreintke]

@slaff :
Yes, that is the location where the freertos heap management is done.
And frankly, I prefer to stay with the freertos version as that is in use in close to all freertos implementations.
The question is not : who is the absloute best
But : Is there an issue with the current one which we need to solve

[patrickjahns]

@slaff
I like it - but needs some more testing in order to ensure it`s stable

@hreintke
there is no issue with the current one - not in a normal way - but with frequent (re-)allocaions the memory could get more fragmented with the current implementation compard to umm

probably when running for longer times and using parts that require a lot of reallocs (using a lot of String class) we could run into more trouble. The webserver can cause quite a few reallocs / allocs and fragment the heap

[hreintke]

@patrickjahns : @slaff :
If there is no issue with the current one, I see no reason for any update.
Only a "probably" is not enough to make a major update like this.

These kind of updates, within the hart of the underlying freertos software, should be kept to an absolute minimum.

[slaff]

If there is no issue with the current one, I see no reason for any update.

@hreintke Sounds reasonable to me concerning RTOS. Then why not merge this PR in NONOS? In NONOS there is an issue with the heap allocation which is easily visible and UMM, integrated in this PR, has better heap allocation. In addition the UMM integration can be switched on and off during compile time with the ENABLE_CUSTOM_HEAP directive.

[hreintke]

@slaff :

Due to the status of Sming NONOS being replaced by SmingRTOS I am not in favor of putting this kind of major updates in.

Why should we put time and effort in a major update in a version for which support will cease on short notice.

[ADiea]

Still noticing some weird behavior of malloc, under investigation see attached png. The last 2 mallocs at 4154 42dc don't seem ok to me

[ADiea]

The issue in the last post was my fault, not reporting all the allocations. I confirm ummaloc works great and should be merged

[hreintke]

@slaff :
As I mentioned two weeks ago

Due to the status of Sming NONOS being replaced by SmingRTOS I am not in favor of putting this kind of major updates in.

Unless we are solving a very high priority issue, I have no intend to merge this in Sming

[hreintke]

No need to merge for NONOS, closing PR