Yes, you can use the component model (and other tooling like WIT) without using WASI.
Yes, the component model is a standard developed under the umbrella of the W3C's WebAssembly Community Group.
That said, while it is relatively stable and hasn't changed much in the last year or so, the component model has not graduated through all the phases of the standardization process yet. It doesn't, for example, have a formal specification yet, although its canonical ABI does have a reference implementation in Python.
Thanks for the heads up. It used to be a `thread_local!`, but switching to a `static mut` resulted in smaller code size. I just forgot to update the code snippet in the article.
> which IIRC requires unsafe access as it's not thread-safe
Yes, and also has no guarantees against mutably aliasing and re-entry.
Note that wasm currently has no shared memory threading (just message passing via FFI through JS and workers), so thread-safety isn't an issue to be wary of here, just re-entry.
> how aggressive is Firefox in holding on to weakly referenced objects?
They are just collected at the next GC slice where they are no longer retained. SpiderMonkey doesn't do anything to try and eagerly collect them. GC slices generally won't happen until either there has been enough pressure (allocations) to trigger one or the user is inactive for N amount of time. There are tons of GC triggering heuristics and some are probably not optimal. It is on the GC team's TODO list to revisit and clean these up.
> does Firefox always continue to allocate memory from the host OS, or is there some threshold where it starts to let things slip?
The threshold of how much is allocated before triggering GC grows as the retained set's size grows. This is bounded by available memory.
For the last year or so, my coworker Jim Blandy and I have been designing and implementing APIs in SpiderMonkey (Firefox’s JavaScript engine) to support various kinds of memory allocation/retention introspection. We are finally shipping a frontend to users as well, and this blog post is an intro to that. This is very much the tip of the iceberg and we wanted to just start shipping since we’ve been building APIs for so long, but this is really a fraction of the things planned. Nightly already has filtering/searching and will soon have import/export of snapshots as well as diffing <http://i.imgur.com/qjWOERs.gif >. Dominator trees and shortest paths from GC roots are incoming as well.
How is this built?
We made an abstraction called “ubi::Node” <https://dxr.mozilla.org/mozilla-central/rev/a8ed7dd831d1969a... > (for “ubiquitous node”) that sees the GC’s heap graph with a traditional nodes-and-edges view so that we don’t have to worry about the difference between (say) an object and some jit code when writing graph analyses. What is cool is that this interface can be backed by either the live heap graph or an offline heap graph. When you save a heap snapshot, we traverse this graph and serialize it into protobuf messages. These can then be reconstructed into an offline graph which you can run analyses on at your leisure.
We also make pretty extensive use of stack capturing, because that is a concrete way to tie retention and GC pressure back to something that feels concrete to users: locations in their source code. I’ve written a bit about how we minimize the overhead of (potentially very frequent) stack captures before by hash consing individual frames so that tails are shared <http://fitzgeraldnick.com/weblog/61/ >. Since then, we have also found a neat way to avoid walking the stack repeatedly if we have already done so once.
If anyone has any questions, please ask away :)
And I made a quick update:
Also, Jim loved writing this comment so much (it is a fun read) that I feel I have to share it :)
Note that the proposal you linked is solving a different (albeit related) problem compared to what I discuss in the article.
That proposal is about formatting the JS-implementation of Java/Clojure/etc specific objects/types at the source-level.
The article is discussing how to even locate a binding's value. The more aggressive your compiler, and the further your source language from JS, the more this becomes a problem that needs solving. However, this is also a problem for people that simply need to debug minified JS and don't want to figure out which source-level variable "aB" refers to, or struggle to figure out that some other source-level constant variable was inlined and can't be inspected by the debugger anymore.
Neither of the two solutions need to block progress on the other. Neither of the two wholly fixes the other's problem, either.
Yes, the component model is a standard developed under the umbrella of the W3C's WebAssembly Community Group.
That said, while it is relatively stable and hasn't changed much in the last year or so, the component model has not graduated through all the phases of the standardization process yet. It doesn't, for example, have a formal specification yet, although its canonical ABI does have a reference implementation in Python.
https://github.com/WebAssembly/component-model/