mnemonik

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.

https://github.com/WebAssembly/component-model/

There is a section in the linked announcement titled "Why use a WebAssembly Runtime?" that hopefully answers your question.

Both Wasmtime and Lucet can AOT compile Wasm, for what it's worth.

There is a DOM story: host bindings. It just isn't implemented yet.

However, that doesn't mean that you can't use it now. wasm-bindgen is essentially a polyfill for host bindings plus some other little things.

Some resources to check out if you want to learn more:

* Host bindings: https://github.com/WebAssembly/host-bindings/blob/master/pro...

* More info about web-sys (web-sys is like the raw libc for the web): https://rustwasm.github.io/wasm-bindgen/web-sys/index.html

* API documentation for web-sys: https://docs.rs/web-sys/0.3.2/web_sys/

* DOM hello world example: https://rustwasm.github.io/wasm-bindgen/examples/dom.html

* A mini MS Paint style example: https://rustwasm.github.io/wasm-bindgen/examples/paint.html

* An FM synth in WebAudio: https://rustwasm.github.io/wasm-bindgen/examples/web-audio.h...

GNU libiberty includes a Rust symbol demangler that you can link: https://github.com/gcc-mirror/gcc/blob/master/libiberty/rust...

Great catch -- thanks for reporting this!

Fix is over in https://github.com/fitzgen/source-map-mappings/pull/15

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.

Thanks for the report!

We've already fixed some of these issues[0] but I didn't update the code snippets in the article -- woops!

[0] https://github.com/tromey/vlq/commit/3b41a2b6c778ce476eaaa28...

.eh_frame is DWARF with a couple tiny tweaks

There is some discussion about power usage in this video by Jack Moffit: https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...

Quantum wiki page with info on how to get involved: https://wiki.mozilla.org/Quantum

I think these are the slides: http://pcwalton.github.io/slides/webrender-talk-022016/

Yup, a patch is in review right now: https://bugzilla.mozilla.org/show_bug.cgi?id=960780

Not sure if you missed it in the parent post, but here is a sneak peek: http://i.imgur.com/qjWOERs.gif

Can you file bug(s) with links to the crash report(s) in about:crashes?

Alternatively, you could email me your crash reports (email in profile) and I could file bug(s) for youe.

Up until a couple months ago, it had an O(n^2) marking algorithm that kept iterating until it got to a fixed point.

Thanks to the hard work of Steve Fink, these days it has an O(n) marking algorithm. See https://bugzilla.mozilla.org/show_bug.cgi?id=1164294 for the details.

Edit to address your questions more directly:

> 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.

Aaaaand I have a meeting I need to go attend.

Yes, it can be enabled all the time with about:config -> privacy.trackingprotection.enabled = true

Yes it is. I also wrote more about the backend implementation on lobste.rs <https://lobste.rs/s/cvtz0x/firefox_s_new_memory_tool >:

Hi folks,

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 :)

https://dxr.mozilla.org/mozilla-central/rev/a8ed7dd831d1969a...

We use this for sampling object allocations to give insight into GC pressure.