Stream: git-wasmtime

Topic: wasmtime / Issue #2210 Store object garbage collection

view this post on Zulip Wasmtime GitHub notifications bot (Sep 19 2020 at 13:51):

Rochet2 opened Issue #2210:

<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->

Feature

<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->
Garbage collection of Store objects that are no longer referenced.
The specification notes:

In practice, implementations may apply techniques like garbage collection to remove objects from the store that are no longer referenced. However, such techniques are not semantically observable, and hence outside the scope of this specification.

From this I infer that the implementing or not implementing such a feature and the details of the implementation are left for the runtime. I imagine that future proposals can affect the implementation this feature. The feature seems to be required in the long term.

Related topics and links:

Benefit

<!-- What is the value of adding this in Cranelift/Wasmtime? -->
Currently Wasm modules can be linked together, but there is no way to unload modules completely. As a result, programs that would require loading modules for temporary use or to conserve memory will "leak memory" as time goes on and eventually the program will run into issues with memory limitations. Garbage collection of objects that are no longer referenced from anywhere would free the memory of those unused objects.

Implementation

<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
One approach is to use reference counting of all objects in a store. With the counting, objects that are no longer referenced can be freed. Cycles of references can exist through the Wasm Table, which means that cycles would need to be detected and all of the objects in the cycle freed if the cycle is not referenced from elsewhere. The garbage collection would be invoked by the runtime itself periodically or when needed. Potentially the collection could be configured or left to the embedder to invoke.

Alternatives

<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
It seems that WAVM has implemented a GC function that can be called by the embedder. https://github.com/WAVM/WAVM/blob/530f33cd30c6ea5114a227175b3a7b0af77cadaa/Lib/Runtime/ObjectGC.cpp#L252
The function to allows garbage collection of unused modules and objects, but it looks like it could only be invoked when the host has control. On the other hand it allows the embedder to have some control on when the collection should occur. The addition of a function to the API for essentially basic functionality that is required in long term may not be something that is wanted as it may never be a part of a standard API for Wasm (for example C-API).

view this post on Zulip Wasmtime GitHub notifications bot (Sep 20 2020 at 20:32):

Rochet2 edited Issue #2210:

<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->

Feature

<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->
Garbage collection of Store objects that are no longer referenced.
The specification notes:

In practice, implementations may apply techniques like garbage collection to remove objects from the store that are no longer referenced. However, such techniques are not semantically observable, and hence outside the scope of this specification.

From this I infer that the implementing or not implementing such a feature and the details of the implementation are left for the runtime. I imagine that future proposals can affect the implementation this feature. The feature seems to be required in the long term.

Related topics and links:

Benefit

<!-- What is the value of adding this in Cranelift/Wasmtime? -->
Currently Wasm modules can be linked together, but there is no way to unload modules completely. As a result, programs that would require loading modules for temporary use or to conserve memory will "leak memory" as time goes on and eventually the program will run into issues with memory limitations. Garbage collection of objects that are no longer referenced from anywhere would free the memory of those unused objects.

Implementation

<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
One approach is to use reference counting of all objects in a store. With the counting, objects that are no longer referenced can be freed. Cycles of references can exist through the Wasm Table, which means that cycles would need to be detected and all of the objects in the cycle freed if the cycle is not referenced from elsewhere. The garbage collection would be invoked by the runtime itself periodically or when needed. Potentially the collection could be configured or left to the embedder to invoke.

Alternatives

<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
It seems that WAVM has implemented a GC function that can be called by the embedder. On the surface it looks like a mark and sweep approach, but I am unsure. https://github.com/WAVM/WAVM/blob/530f33cd30c6ea5114a227175b3a7b0af77cadaa/Lib/Runtime/ObjectGC.cpp#L252
The function to allows garbage collection of unused modules and objects, but it looks like it could only be invoked when the host has control. On the other hand it allows the embedder to have some control on when the collection should occur. The addition of a function to the API for essentially basic functionality that is required in long term may not be something that is wanted as it may never be a part of a standard API for Wasm (for example C-API).

view this post on Zulip Wasmtime GitHub notifications bot (Sep 20 2020 at 20:33):

Rochet2 edited Issue #2210:

<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->

Feature

<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->
Garbage collection of Store objects that are no longer referenced.
The specification notes:

In practice, implementations may apply techniques like garbage collection to remove objects from the store that are no longer referenced. However, such techniques are not semantically observable, and hence outside the scope of this specification.

From this I infer that the implementing or not implementing such a feature and the details of the implementation are left for the runtime. I imagine that future proposals can affect the implementation this feature. The feature seems to be required in the long term.

Related topics and links:

Benefit

<!-- What is the value of adding this in Cranelift/Wasmtime? -->
Currently Wasm modules can be linked together, but there is no way to unload modules completely. As a result, programs that would require loading modules for temporary use or to conserve memory will "leak memory" as time goes on and eventually the program will run into issues with memory limitations. Garbage collection of objects that are no longer referenced from anywhere would free the memory of those unused objects.

Implementation

<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
One approach is to use reference counting of all objects in a store. With the counting, objects that are no longer referenced can be freed. Cycles of references can exist through the Wasm Table, which means that cycles would need to be detected and all of the objects in the cycle freed if the cycle is not referenced from elsewhere. The garbage collection would be done immediately when possible or invoked by the runtime itself periodically or when needed. Potentially the collection could be configured or left to the embedder to invoke.

Alternatives

<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
It seems that WAVM has implemented a GC function that can be called by the embedder. On the surface it looks like a mark and sweep approach, but I am unsure. https://github.com/WAVM/WAVM/blob/530f33cd30c6ea5114a227175b3a7b0af77cadaa/Lib/Runtime/ObjectGC.cpp#L252
The function to allows garbage collection of unused modules and objects, but it looks like it could only be invoked when the host has control. On the other hand it allows the embedder to have some control on when the collection should occur. The addition of a function to the API for essentially basic functionality that is required in long term may not be something that is wanted as it may never be a part of a standard API for Wasm (for example C-API).

view this post on Zulip Wasmtime GitHub notifications bot (Nov 09 2020 at 12:56):

Rochet2 edited Issue #2210:

<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->

Feature

<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->
Garbage collection of Store objects that are no longer referenced.
The specification notes:

In practice, implementations may apply techniques like garbage collection to remove objects from the store that are no longer referenced. However, such techniques are not semantically observable, and hence outside the scope of this specification.

From this I infer that the implementing or not implementing such a feature and the details of the implementation are left for the runtime. I imagine that future proposals can affect the implementation this feature. The feature seems to be required in the long term.

Interestingly, the module linking proposal has a requirement not to use a GC. That requirement potentially affects this feature's implementation.

Related topics and links:

Benefit

<!-- What is the value of adding this in Cranelift/Wasmtime? -->
Currently Wasm modules can be linked together, but there is no way to unload modules completely. As a result, programs that would require loading modules for temporary use or to conserve memory will "leak memory" as time goes on and eventually the program will run into issues with memory limitations. Garbage collection of objects that are no longer referenced from anywhere would free the memory of those unused objects.

Implementation

<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->
One approach is to use reference counting of all objects in a store. With the counting, objects that are no longer referenced can be freed. Cycles of references can exist through the Wasm Table, which means that cycles would need to be detected and all of the objects in the cycle freed if the cycle is not referenced from elsewhere. The garbage collection would be done immediately when possible or invoked by the runtime itself periodically or when needed. Potentially the collection could be configured or left to the embedder to invoke.

Alternatives

<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->
It seems that WAVM has implemented a GC function that can be called by the embedder. On the surface it looks like a mark and sweep approach, but I am unsure. https://github.com/WAVM/WAVM/blob/530f33cd30c6ea5114a227175b3a7b0af77cadaa/Lib/Runtime/ObjectGC.cpp#L252
The function to allows garbage collection of unused modules and objects, but it looks like it could only be invoked when the host has control. On the other hand it allows the embedder to have some control on when the collection should occur. The addition of a function to the API for essentially basic functionality that is required in long term may not be something that is wanted as it may never be a part of a standard API for Wasm (for example C-API).

Last updated: Nov 22 2024 at 17:03 UTC