nteon

the downside is that the go runtime doesn't expect memory reads to page fault, so you may end up with stalls/latency/under-utilization if part of your dataset is paged out (like if you have a large cdb file w/ random access patterns). Using file IO, the Go runtime could be running a different goroutine if there is a disk read, but with mmap that thread is descheduled but holding an m & p. I'm also not sure if there would be increased stop the world pauses, or if the async preemption stuff would "just work".

Section 3.2 of this paper has more details: https://db.cs.cmu.edu/papers/2022/cidr2022-p13-crotty.pdf

In Go, overflow is not checked, but it is well-defined in the spec including `programs may rely on "wrap around"`: https://go.dev/ref/spec#Integer_overflow

you are right -- EROI and emissions are different. If you add in things like carbon capture, emissions go down but energy-in goes up. Would it make sense to extract and refine gasoline with net-0 emissions if it took more energy than you get out in gasoline? _maybe_, but I don't think its a clear yes!

Yes they did. Here is one such demo: https://leaky.page/

How did you get COOP/COEP in Github pages? A quick search just now suggested it might be possible with a Service Worker[0], with the caveat that it may only work on _second_ load.

0 - https://dev.to/stefnotch/enabling-coop-coep-without-touching...

I think there is a straightforward path to having Browsix generically support the WebAssembly WASI system interface[0] -- any toolchain that emitted binaries targeting that would then work in Browsix without e.g. Emscripting needing to know anything about Browsix.

0 - https://wasi.dev

I'm one of the authors - its so exciting to see continued interest here!

The biggest problem with Browsix today stems from Spectre mitigations: Shared Array Buffers aren't enabled by default in browsers, and static hosting sites like GitHub Pages don't let you set the right COOP/COEP ( https://web.dev/coop-coep/ ) headers to get them enabled AFAICT.

Additionally, Browsix hasn't been updated in a while, although I still believe the idea is sound. I don't have a lot of time for Browsix these days, but it would be straightforward to update Browsix with WASI support which would free us from having to use a modified Emscripten toolchain (and instantly enable running Rust binaries under Browsix).

[edit]: for additional context: we use Shared Array Buffers to give the kernel and program a shared view of a process's address space to enable fast system calls between Web Workers and the kernel (running in the main browser thread/context). Without them performance is unacceptably slow, as things like read/write system calls (a) require several memcpys and (b) create a bunch of JS garbage. Additionally, without them there isn't a good way to "block" handling a syscall in a WebWorker (which we need to do for non-event-loop C/C++/Rust programs).

That's pretty right, with the addition that other things can target Browsix (like the gopherjs toolchain). Emscripten provides default implementations of a bunch of syscalls (and even a way to embed a file system), and we override those to instead do actual syscalls to a shared kernel (running in JS)

(author here) Without something like Browsix you have to make a choice: find a JavaScript library or implement the functionality you want to run client side, or run existing Unix programs and libraries (that expect a filesystem, to be able to fork children, etc) server side. If you run software server side, now you have to worry about containerizing/security as well as horizontal scaling.

Browsix addresses this by letting you run Unix programs directly in the browser, taking advantage of the significant compute power on peoples laptops (and even phones nowadays!), eliminating a whole class of security issues (software explicitly will only have access to the current users data in the browser tab) and scaling concerns.

(one of the authors here) it was written in Typescript from the start! Typescript eliminated a bunch of type confusion errors when developing the kernel, although the need to marshal data across a MessagePort means we have to do some casting and lose some safety.

(444) 444-4444 also works

Can you compare `tcmalloc` to e.g. tcmalloc dynamically loaded, or jemalloc specified with Bazel's malloc option? It is unclear from the post whether the wins are improvements from the internal Google improvements to tcmalloc post-gperftools, or to reduction in overhead from bypassing the PLT

WASI provides a cross platform definition of "system calls" ( https://github.com/WebAssembly/WASI/blob/master/design/WASI-... ), so that you could write a program, compile it for wasm+wasi, and run the program on any implementation that provides those system calls, like cranelift on Linux, something on Windows, Browsix in the browser.

Browsix and Browsix-Wasm were developed before Wasm and WASI respectively were available, so they have their own definition of syscalls that are conceptually similar but not exactly binary compatible. We hope to modify Browsix to support running programs targeting WASI in the browser, which would free us from having to maintain our own fork of Emscripten.

Do you have specific decentalized apps or usecases in mind? We would love to hear more about the use cases of running things like that in the browser (and have done some work to make socket connections between programs in different browser tabs work over WebRTC)

(I'm one of the authors of Not So Fast)

In the paper we build on previous work from our group, Browsix ( https://browsix.org ) to provide a similar level of abstractions to WASI (the syscall layer). We've talked about having Browsix support running programs targeting WASI in the browser.

One of the great things about supporting "Unix" in the browser is that it makes bringing a whole class of already written applications and library into the browser. I'm excited to see what people do with WASI, but its not clear to me what a program designed from the ground up around capabilities would look like!

Well, there are 2 sides to increasing page sizes. If you can fit more objects on a page, there is a higher chance of collision at a given occupancy %, reducing the effectiveness of meshing. On the other hand, it means that very low occupancy pages (like single allocations) would cause an even larger amount of memory to be held onto by a process - a situation Mesh would be able to handle well.

We didn't look at huge pages in the paper for the reason that today, if you care most about heap footprint you can always use 4K pages rather than 2M ones. (and lots of database-like applications, like Redis, explicitly suggest disabling huge pages)

This sounds right - that line was written before Rust used the system allocator by default. Will update, although I'm still itching to write a GlobalAlloc implementation.

Hi! I'm one of the authors -- thanks so much!

We thought similarly about cache performance, but weren't able to find specific examples (most of the slow benchmarks we dug into were due to unoptimized allocator performance rather than poorer caching).

Informally I think one of the reasons for this is that in long running problems, allocations returned from malloc end up being pretty random rather than contiguous -- as allocations are freed they are put in freelists, and freelists are designed more for temporal locality rather than spatial.

It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance, or introducing crazier and unsound primitives (like stack manipulation).

I've used SharedArrayBuffers to port things like latex into the browser ( https://browsix.org ), and without it you can't use wasm or asm.js, you need to interpret C code in JavaScript to save/restore the stack on system calls.

GopherJS is _not_ an emulator. Saying that it emulates a 32-bit environment means that `int` (which is architecture-specific in Go) is 4 bytes (compared to 8-bytes on amd64), and means that int64 is supported and does what you expect.

As a counterexample -- it is not possible to have a 33 LOC example that uses goroutines to only expand to 44 LOC. GopherJS goes to extremes to make sure that your Go code works as expected in the browser.

Please take a look at the contributions in the paper at the end of the introduction. The JVM uses operating system abstractions (like a file system, threads, and synchronous APIs) that were non-existent in the browser when the paper were published, and are still widely unavailable natively. Figuring out how to construct the functionality necessary not to just simply execute Java bytecode but to provide a full Java Virtual Machine, and then show how this could be generalized beyond a JVM, is a CS contribution. Disclosure: I'm a labmate of the author.

Doppio relies heavily on the Javascript object model, the asm.js subset of Javascript isn't very relevant.

yes -- it implements Java objects on top of Javascript objects.

I think the most compelling use case is running legacy code in the browser (and in applications like Atom and Visual Studio Code) - like our Latex example.

Another good use case are command line tools like graphviz. Someone wrote a wrapper around an emscriptenized Graphviz that looks great, but Browsix should lower the bar for using great existing tools like these from JavaScript.

JSLinux is a tremendous feat of engineering.

If you want to run realistic programs in the browser (and not just technology demos), WebAssembly, asm.js, and compilation to JavaScript in general is the way to go. WebAssembly can easily execute within a factor of 2 of optimized GCC binaries, whereas JSLinux is ~80x slower.

Paired with compilers like Emscripten and GopherJS Browsix has the potential to be a relatively fast and lightweight solution to running legacy code in the browser in a way that integrates with existing tools for web UIs.

Yes! GopherJS has been amazing to work with.

The majority of our changes (https://github.com/bpowers/browsix-gopherjs) amount to an alternative implementation of the compiler/natives/syscall package (we started before GopherJS had its own filesystem implementation). This lets us use the stack saving + resuming support GopherJS already has to implement blocking system calls.

That was our first shell we used for debugging before we had emscripten working.

The shell currently used in the demo is dash, compiled with emscripten: https://github.com/plasma-umass/browsix/blob/master/src/dash...

Which ends up in the build through our gulpfile: https://github.com/plasma-umass/browsix/blob/master/gulpfile...

The shell is dash, compiled from C. We run each command as

dash -c "$COMMAND"

Processes can change their current directory (We support the chdir(2) system call), but the way the shell demo is currently implemented no state is retained between command invocations. We plan to address this shortcoming soon as part of a bigger TTY refactoring.

We already work with asm.js, and I've gotten some WebAssembly prototypes running under Browsix as well. Browsix is nicely orthogonal to those projects -- WebAssembly lets you compile existing C/C++/Rust code to run in the browser with almost no overhead, and Browsix gives you the environment your program expects (pipes, sockets, a filesystem, subprocesses).

That example is actually running dash - the Debian Almquist shell.

The weirdness (and reason that cd + setting variables doesn't work) is because whenever you type a command in, it executes:

$ dash -c '$COMMAND'

Rather than having a long-running shell process listing to standard in. We plan to fix this and implement a full TTY subsystem in the next month or so.

Hi - main author here.

Browsix is not an interpreter. Browsix provides a shared kernel and primitives like system calls to _existing_ interpreters and runtimes that target JavaScript.

For example, we extended both the GopherJS and Emscripten compilers and runtimes to talk to our shared kernel, so that processes written in C and Go can run in parallel (on separate Web Workers) and communicate over pipes, sockets and the filesystem in the browser (much like they can in a standard Unix environment).