wasm: improve memory management strategy #1121
Comments
|
@tsandall The Could this make it a more urgent issue as it seems a memory consumption issue rather than only a latency issue? |
|
@t83714 yes this a blocker to using the wasm support in non-trivial cases. We'll hopefully find time to work on this in the next month or so. |
|
@tsandall Thanks a lot for the update 👍 I was trying to figure out something similar to this for As I had to use a fixed size java I actually was not 100% sure whether it's the issue of the scala wasm runtime I used or the issue of OPA memory allocation --- not very familiar with the C code 😄 Glad to know it's been covered by your plan already 👍 |
The memory.grow calls were dominating the evaluation time and the integration tests were beginning to take way too long to run. This just updates the opa_malloc placeholder to keep track of the heap and only call memory.grow when needed. We can revisit memory management in the future but for now this is good enough. Fixes open-policy-agent#1121 Signed-off-by: Torin Sandall <torinsandall@gmail.com>
The memory.grow calls were dominating the evaluation time and the integration tests were beginning to take way too long to run. This just updates the opa_malloc placeholder to keep track of the heap and only call memory.grow when needed. We can revisit memory management in the future but for now this is good enough. The opa_object and opa_set functions had to be fixed to zero out their members so that the same memory could be re-used across multiple evals. Fixes open-policy-agent#1121 Signed-off-by: Torin Sandall <torinsandall@gmail.com>
The memory.grow calls were dominating the evaluation time and the integration tests were beginning to take way too long to run. This just updates the opa_malloc placeholder to keep track of the heap and only call memory.grow when needed. We can revisit memory management in the future but for now this is good enough. The opa_object and opa_set functions had to be fixed to zero out their members so that the same memory could be re-used across multiple evals. Fixes #1121 Signed-off-by: Torin Sandall <torinsandall@gmail.com>
The current malloc implementation in the WASM-C library grows the heap by the required page count each time it's called (which is expensive and inefficient.) Rough benchmarks show that the latency is dominated by the heap operations. For the initial implementation, it may be possible to allocate the heap once.
The text was updated successfully, but these errors were encountered: