• Native stack overflow checking is a good practice. However, besides that, memory (allocated) is another resource that can be exhausted due to recursion. So, I am considering directly limiting the nesting level to protect against both stack overflow and out-of-memory issues. Please share your comments.
• We need a few regression test cases to cover these scenarios.

• Native stack overflow checking is a good practice. However, besides that, memory (allocated) is another resource that can be exhausted due to recursion. So, I am considering directly limiting the nesting level to protect against both stack overflow and out-of-memory issues. Please share your comments.

for multiple levels of nesting, currently appears to handle this properly(just return NULL, to avoid heap overflow), this behavior seems inherently equivalent to creating numerous struct/array objects. If I'm wrong, please let me know.

Yes and no. Theoretically, whether it's the stack or heap, if they happen to be exhausted at the time of these two wasm_xxx_obj_new() calls, they can gracefully return an error and exit.

However, in practice, there are many functions and allocations along the chain of executing nested structs/arrays. Each point could potentially lead to resource exhaustion and an exception. Unless intercepted at the very beginning, it's challenging to catch all such instances during execution.

Still, don't forget to add a few regression test cases to cover these scenarios.

So, I am considering directly limiting the nesting level to protect against both stack overflow and out-of-memory issues. Please share your comments.

Agreed, I also think directly limiting the nesting level is a clearer standard, it can give more meaningful error info like "reach max recursion level" rather than "stack/heap overflow"