[instantiation linking] Optimize aot func inst list #4018
Conversation
…pawned' for clarity in deinstantiation functions
…ecks and improving error handling
…nagement functions
…conv_wasm_c_api and call_conv_raw in WASM function structures
… for function instantiation
…pport and improve error logging
…pport and improve error handling
… support and improve clarity
…structure and improving function import handling
… support and clarity
…prove function instance lookup
lum1n0us
requested review from
loganek,
no1wudi,
wenyongh,
xujuntwt95329 and
yamt
as code owners
core/iwasm/aot/aot_runtime.c
Outdated
| extra->function_count = module->import_func_count + module->func_count; | ||
| if (extra->function_count > 0) { | ||
| extra->import_functions = | ||
| functions_instantiate(module_inst, module, imports, import_count, |
There was a problem hiding this comment.
how about renaming it to import_functions_instantiate?
| { | ||
| AOTFunctionInstance *function = runtime_malloc( | ||
| sizeof(AOTFunctionInstance) + sizeof(AOTImportFunc), NULL, 0); |
There was a problem hiding this comment.
A little confused why need to plus sizeof(AOTImportFunc)?
There was a problem hiding this comment.
I am considering that this would enable host APIs (defined in wasm_export.h) to create an AOTFunctionInstance from scratch and pass it to the runtime for execution. The runtime would then use the u.func_import field to retrieve some information. However, there might be room for optimization in subsequent pull requests.
| wasm_create_function_empty(const WASMModule *module) | ||
| { | ||
| WASMFunctionInstance *function = runtime_malloc( | ||
| sizeof(WASMFunctionInstance) + sizeof(WASMFunctionImport), NULL, 0); |
There was a problem hiding this comment.
Is it necessary to allocate extra memory (+ sizeof(WASMFunctionImport))?
However, this does not align with the specification definition. I believed the purpose of creating the "instantiation linking" series of pull requests was to align with the specification requirements. Otherwise, our main branch code is functioning quite well. |
It reports the error during the execution time but not instantiation time, it doesn't strictly obey the spec. But sometimes the user experience is more important, in fact, we also do some special handlings in other places. I still think it is good to keep it, it also reports error and it is more friendly to developers. |
…nce memory allocation consistency
| } | ||
|
|
||
| return func_ptr; | ||
| } |
There was a problem hiding this comment.
the function body is a little big, is it better to make it no-inlined?
lum1n0us
merged commit 918b364
into
bytecodealliance:dev/instantiate_linking
#3947 (comment)