AP_Scripting: allow expansion of memory for scripting at runtime #26517

tridge · 2024-03-15T02:53:19Z

This makes it possible to expand the MultiHeap used by scripting at runtime. This means if the user underestimates the right value for SCR_HEAP_SIZE and they have free memory (which they usually do on a H7) then it will allocate more memory with a warning
Note that:

it will only expand the heaps if armed. If disarmed the user must fix their SCR_HEAP_SIZE
expanding can be disabled with a SCR_DEBUG_OPTS option

This PR also cleans up the handling of scripting debug options

The motivation for this PR is there is really no way to predict in advance how much memory a set of scripts will need, so users may under-estimate and the scripts fail at a critical time

This PR also fixes an issue where realloc may fail if there is no room in the current sub-heap. We now always alloc/copy/ree. ChibiOS was doing this within a heap already, so this doesn't cost any more, but means it fixes a path for script failure

This was test flown on a Pixhawk6X

IamPete1 · 2024-03-18T12:49:11Z

My only real concern is that the user won't notice. I think we should call the error handler in scripting so it will make a fuss and print the warning lots and will trigger a pre-arm. If we do that I think its fine to allow it to run when disarmed too. Currently just running out of memory only tells you that there is not enough, I think this method would be able to tell how much is needed. Ideally the users gets this error then puts the value into the heap size param and then never sees it again.

tridge · 2024-03-18T19:16:36Z

I think we should call the error handler in scripting so it will make a fuss and print the warning lots and will trigger a pre-arm

that would make their script fail, which loses the main reason for this PR which is to handle cases where a less common path in a script (eg. a failsafe handling) takes you over your memory limit and a critical script fails
we could make it an InternalError, but I suspect @peterbarker would object as it is really not an internal error

IamPete1 · 2024-03-18T22:31:50Z

that would make their script fail, which loses the main reason for this PR which is to handle cases where a less common path in a script (eg. a failsafe handling) takes you over your memory limit and a critical script fails

Sorry, bad wording, I didn't mean you actually error out, just call the set_and_print_new_error_message method. That is what will reprint the error a lot and cause a pre-arm. Ideally with a message something like "need SCR_HEAP_SIZE > x"

timtuxworth · 2024-03-18T23:28:56Z

When this says "makes it possible", what does that mean? From the dev call discussion it sounded like the RAM will be automatically allocated if needed when armed, which actually makes sense, but that's a bit more proactive than "makes it possible". Could you make it a bit clearer what's actually happening?

tpwrules

Some notes to make things cleaner.

tpwrules · 2024-04-06T15:24:01Z

libraries/AP_Common/MultiHeap.h

@@ -23,7 +23,19 @@ class MultiHeap {
    // size, unlike realloc()
    void *change_size(void *ptr, uint32_t old_size, uint32_t new_size);

+    struct alloc_header {
+        void *heap;


This is going to bump the size of every allocation by four bytes. Do we know how many allocations a typical scripting environment uses? Is four bytes sufficient alignment for the allocation?

tpwrules · 2024-04-06T15:25:13Z

libraries/AP_Scripting/lua_scripts.cpp

    : _vm_steps(vm_steps),
      _debug_options(debug_options),
     terminal(_terminal)
 {
-    _heap.create(heap_size, 4);
+    const bool allow_heap_expansion = !option_is_set(AP_Scripting::DebugOption::DISABLE_HEAP_EXPANSION);
+    _heap.create(heap_size, 10, allow_heap_expansion, 20*1024);


The reserve size is 10K smaller than the minimum allocation size. Therefore the check is redundant, and a successful heap allocation could leave 0 bytes free.

tpwrules · 2024-04-06T15:26:00Z

libraries/AP_Common/MultiHeap.cpp

+    // round up to multiple of 30k to allocate, and allow for heap overhead
+    const uint32_t alloc_size = MAX(size+heap_overhead, 30*1024U);


I don't think this can be described as rounding.

tpwrules · 2024-04-06T15:27:07Z

libraries/AP_Common/MultiHeap.cpp

+#ifdef HAL_DEBUG_BUILD
+    if (ptr != nullptr) {
+        struct alloc_header *h = ((struct alloc_header *)ptr)-1U;
+        if (h->size != old_size) {
+            INTERNAL_ERROR(AP_InternalError::error_t::invalid_arg_or_result);
+        }
+    }
+#endif


This makes the check done by Util::heap_realloc redundant; that check should be removed.

tpwrules · 2024-04-06T15:28:37Z

libraries/AP_Common/MultiHeap.cpp

+        if (heaps[i] == nullptr) {
+            heaps[i] = hal.util->allocate_heap_memory(alloc_size);
+            if (heaps[i] == nullptr) {
+                return nullptr;


Do we need to try smaller sizes due to the multiple memory block concern like is done on init?

tpwrules · 2024-04-06T15:30:26Z

libraries/AP_Common/MultiHeap.cpp

-    // not using the first argument when size is zero.
-    hal.util->heap_realloc(heaps[0], ptr, 0, 0);
+    struct alloc_header *h = ((struct alloc_header *)ptr)-1U;
+    hal.util->heap_realloc(h->heap, h, 0, 0);


Now that we only use Util::heap_realloc as malloc or free, should it be split into two functions? That would simplify its implementation.

this allows for new heaps to be added at runtime for lua scripting if you run out of memory while armed

tridge added Scripting DevCallTopic labels Mar 15, 2024

tridge force-pushed the pr-lua-malloc-expand branch from f942493 to f91f37c Compare March 15, 2024 07:08

CraigElder removed the DevCallTopic label Mar 18, 2024

Hwurzburg added the WikiNeeded needs wiki update label Mar 18, 2024

tpwrules reviewed Apr 6, 2024

View reviewed changes

tridge added 3 commits May 11, 2024 15:31

AP_Scripting: cleanup debug option handling

2e415cc

AP_Scripting: added ability to expand heap at runtime if armed

1060f05

AP_Common: allow expansion of heaps in MultiHeap

98c2963

this allows for new heaps to be added at runtime for lua scripting if you run out of memory while armed

tridge force-pushed the pr-lua-malloc-expand branch from f91f37c to 98c2963 Compare May 11, 2024 07:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AP_Scripting: allow expansion of memory for scripting at runtime #26517

AP_Scripting: allow expansion of memory for scripting at runtime #26517

tridge commented Mar 15, 2024 •

edited

IamPete1 commented Mar 18, 2024

tridge commented Mar 18, 2024

IamPete1 commented Mar 18, 2024

timtuxworth commented Mar 18, 2024

tpwrules left a comment

tpwrules Apr 6, 2024

tpwrules Apr 6, 2024

tpwrules Apr 6, 2024

tpwrules Apr 6, 2024

tpwrules Apr 6, 2024

tpwrules Apr 6, 2024

		// round up to multiple of 30k to allocate, and allow for heap overhead
		const uint32_t alloc_size = MAX(size+heap_overhead, 30*1024U);

AP_Scripting: allow expansion of memory for scripting at runtime #26517

Are you sure you want to change the base?

AP_Scripting: allow expansion of memory for scripting at runtime #26517

Conversation

tridge commented Mar 15, 2024 • edited

IamPete1 commented Mar 18, 2024

tridge commented Mar 18, 2024

IamPete1 commented Mar 18, 2024

timtuxworth commented Mar 18, 2024

tpwrules left a comment

Choose a reason for hiding this comment

tpwrules Apr 6, 2024

Choose a reason for hiding this comment

tpwrules Apr 6, 2024

Choose a reason for hiding this comment

tpwrules Apr 6, 2024

Choose a reason for hiding this comment

tpwrules Apr 6, 2024

Choose a reason for hiding this comment

tpwrules Apr 6, 2024

Choose a reason for hiding this comment

tpwrules Apr 6, 2024

Choose a reason for hiding this comment

tridge commented Mar 15, 2024 •

edited