On Mon, 13 Nov 2023 08:39:15 +1300, Peter Reutemann quoted:
'In Chrome, JavaScript (and WebAssembly) code are both executed by Google's open source V8 engine — which already has garbage-collecting capabilities. "This means developers making use of, for example, PHP compiled to Wasm, end up shipping a garbage collector implementation of the ported language (PHP) to the browser that already has a garbage collector," writes Google developer advocate Thomas Steiner, "which is as wasteful as it sounds."'
Particularly if you have to implement your own memory-management scheme because the provided one doesn’t work right. People have built implementations of Python, Java and other languages entirely in WebAssembly. But if the underlying memory management doesn’t do what you need it to do, you have to forget it and reimplement your own. As far as I can tell from a quick skim of the spec <https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md>, there is no support for reference-counted memory management, only for pure GC. As you may know, languages like Python (at least the CPython implementation) and Perl use a hybrid scheme, where dynamically-allocated objects have a reference count attached to them, so objects can be immediately freed when the count goes to zero. This works for a lot of cases, except where one object contains a reference that directly or indirectly points back to itself. Then the counts for the objects in the cycle never go to zero, so you have to resort to a garbage collector to clean them up. I think the term for this is “ORC”, where the “O” actually represents the cycles, while the “RC” stands for “Reference Counting”. The simpler, not to say simplistic, alternative is “ARC”, which stands for “Automatic Reference Counting”, which really means “Reference Counting And Nothing Else”. It could be that this terminology comes from Nim <https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html>.