Make all dynamic memory allocations via core API functions in jerry-ext

[akosthekiss]

Direct calls to malloc and free should be avoided,
jerry_heap_alloc and jerry_heap_free should be used in their
place. Build-time configuration should decide whether those calls
manage dynamic memory on the engine's heap or on the system heap.

JerryScript-DCO-1.0-Signed-off-by: Akos Kiss akiss@inf.u-szeged.hu

[lygstate]

LGTM

[rerobika]

LGTM

[zherczeg]

JerryX should not rely on any internal things. That is a key design principle.

[akosthekiss]

@zherczeg jerry-ext should not rely on any internal functions, true. But jerry_heap_alloc and jerry_heap_free are public API, not internal routines (those would be their ecma_... counterparts). And using jerry API memory allocation routines is definitely better aligned with the memory management of the rest of the engine than malloc/free. Using the system memory allocator would force jerry-ext users to have two allocation mechanisms in parallel (if they configure the engine to use its own), or would prevent the use of jerry-ext (if system allocator is not available).

BTW, jerry-ext/debugger is already using jerry_heap_... routines, for the same reasons, I guess.

[zherczeg]

True, I forgot these functions are exported.

In general, what is the gain here? Jerry allocator is better than the system allocator, or we don't expect to have enough memory provided by the system? I would prefer allocating everything with malloc outside of JerryScript.

[akosthekiss]

Well, "outside" JerryScript, i.e., an embedder application does whatever it want. It knows very well what the platform allows or disallows. It knows whether using system allocator is OK or not. But the engine was designed to be able to run on systems where the system allocator must not be used for dynamic memory allocation (that's why it has its own heap, if configured so, and its own memory allocators).

But jerry-ext is kind of a grey zone. It is not the core of the engine, it must not use internal routines, but it shall be "universal". Wherever the engine can work, the extensions should work, too (there may be some exception to that, but they should be the exceptions, not the rule). Therefore, if an extension needs dynamic memory, it should allocate that via the jerry_heap_... API functions. (And then, depending on the configuration of the engine, that will be channeled through either to the engine's allocator, or to the system allocator.) If that would not be the case, perhaps the public heap API functions would not even be needed.

[zherczeg]

Would it be a good idea to make this configurable (jerry-ext can or cannot use malloc)? So people could choose the best for them. The default can be not to use it.

[lygstate]

Would it be a good idea to make this configurable (jerry-ext can or cannot use malloc)? So people could choose the best for them. The default can be not to use it.

jerryx_heap_free and jerryx_heap_malloc

[akosthekiss]

@zherczeg I'd keep configuration options to a minimum. Especially in this case. At least, for now. Adding that configurability would also mean adding a new memory management layer, even if thin.

Something like jerryx_heap_alloc (or JERRYX_HEAP_ALLOC) would be needed, which would either get translated to malloc or jerry_heap_alloc (depending on jerry-ext configuration), which in turn can get translated to malloc or jmem_... (depending on jerry-core configuration). This sound a bit overly/unnecessarily complex to me with those cascaded decisions.

Whether that should be implemented, I'd leave for a follow-up feature implementation PR (not by me).

[ossy-szeged]

LGTM