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.

There are a few here and there and they seem to be getting somewhat more popular (to my delight). One of the bigger names is Igalia.

https://wingolog.org/archives/2013/06/05/no-master

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.

asm.js made wasm possible by creating a solid compatibility story and evolutionary path.

I don't think that is generally true. Sweeping has much better cache locality than marking, which is following pointers all over who-knows-where in the heap.

FWIW, I've found the Guide incredibly helpful, and in general found the docs very satisfying. (Although I do wish the pointers guide was more complete :) )

The API docs + search in the docs are incredible IMO. I'm in absolute love with rustdoc. Having links to the source right there is the most valuable thing ever, both when trying to understand how to use a given API, and when trying to write similar things its really useful to be able to look at how others have done things.

Related blog post: https://blog.mozilla.org/blog/2014/11/19/promoting-choice-an...

More details, Yandex in Russia and Baidu in China, etc.

All of the potential partnerships (including going with Google again) offered an improvement economically over the last deal partnership.

Mozilla chose not to go with Google again.

Here is an excellent 18 minute piece on the Amen Break, mentioned in TFA:

https://www.youtube.com/watch?v=5SaFTm2bcac

Down for me. Here's a wayback machine cached version: https://web.archive.org/web/20140226025639/http://tobyrush.c...

If you find this interesting, you might also enjoy "A Unified Theory of Garbage Collection" by Bacon et all: http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

This is a great question, thanks for asking.

For crashes, definitely submitting the crash report found in about:crashes helps a ton.

Checking the browser console for an error message + stack and pasting that in a bug + description of bad behavior can be useful.

Finally, in extreme cases you can enable all the devtools logging[0] and then run firefox while piping stdout into a log file. This is a firehose of information, but it should hopefully point to the part of the code base that is misbehaving.

[0] https://wiki.mozilla.org/DevTools/Hacking#Enabling_DevTools_...

It might be just me, but it's very common when I use the JavaScript debugger in Firefox that it either freezes the site, the debugger, or Firefox itself.

If you have a test case and steps to reproduce, please file a bug! We can't usually fix the bugs we don't know about.

Works for me:

    > c = console
    Console {  }
    > window.console = {}
    Object {  }
    > c.log("hello")
    undefined
    "hello"