doppio

Doppio (https://github.com/plasma-umass/doppio) is exactly this: a POSIX layer (for a single process), while Browsix is a Unix layer. Both are JS only. Doppio implements a ton of libc functionality, enough to host a full JVM interpreter (see http://plasma-umass.github.io/doppio-demo/). Doppio contains BrowserFS (available separately as https://github.com/jvilk/BrowserFS), an in-browser file system that abstracts over local storage and lets you mount remote filesystems like Dropbox, Zip files, and more. Archive.org is using it for all of its DOS and Windows games.

My conjecture: Scheduling with priority is pretty easy across these systems. The dependency graph transfer would be outside the scope of what they already tackle, and require new engineering. In Pyret, I prototyped virtual threads at one point, and each thread had the same amount of "fuel" before yielding (at the top of every compiled function in Pyret, there's a decrement to a "fuel" counter, and when it reaches zero, the stack is unwound). That could easily be configured on each start/restart of a thread to provide different amounts of fuel, or to re-order the restarts based on typical thread-scheduling policies. Whalesong does the same thing with fuel, so I imagine it could be extended similarly. I don't know how Doppio and GopherJS do scheduling in detail, but here's where I'd start looking: 1. GopherJS looks like it's a simple que

Part of these notes, Fiber [0], reminds me of a half-joking "corollary" to Greenspun's Tenth Rule (credit @shriramkmurthi): Any sufficiently complicated JavaScript program contains an ad hoc, informally-specified, bug-ridden, slow implementation of delimited continuations. Control over continuations and the stack is our main compiler and runtime engineering hurdle in Pyret. Projects like Doppio [1], WeScheme [2] and GopherJS [3] go through staggering amounts of overhead and effort to get pausable, resumable, and stoppable computation in the browser environment. I'm excited to see how this develops in React with fiber. It's much more application-specific, but it's the same underlying problem. [0] https://facebook.github.io/react/contributing/codebase-overv... [1] https://github.com/plasma-umass/doppio [2] https://cs.brown.edu/~sk/

One of Doppio's explicit goals was to leverage existing resources in the browser to bring conventional programming languages to the web on top of JavaScript. Using WebAssembly would prevent Doppio from using the browser's garbage collector; we would have to write our own. It would also prevent Doppio from mapping JVM objects onto JavaScript objects. The WebAssembly standard is constantly evolving, and now contains some ambiguous statements regarding the ability to take advantage of the browser's GC [0]. Considering WebAssembly's current focus on C/C++ code, I do not believe this will come to fruition anytime soon. If it does, I do not see how it would noticeably improve Doppio's current performance, which is bottlenecked primarily by its interpreter. A contributor is working on a JIT right now to make execution faster [1]. Hope that clari

The main goal of Doppio was never speed -- it was compatibility [0]. It's actually a JVM interpreter at present, leading to noticeable slowdown over a native JVM. Thus, there are many opportunities for performance improvements! A recent contributor is starting to add a JIT to Doppio, which is a step in the right direction [1]. [0] Our academic paper from PLDI 2014 has more details, although the project has evolved since then (it's now JDK8 compatible, for example): https://plasma-umass.github.io/doppio-demo/paper.pdf [1] https://github.com/plasma-umass/doppio/pull/443

The last time I checked, doppio can run the Closure compiler [0]. [0] https://github.com/plasma-umass/doppio/issues/317

I actually embarked on a similar Python VM called Ninia [1] awhile back, but shelved it as other projects became more important. Ninia supports multiple threads and preempts execution to give the browser breathing space, just like my JVM in JavaScript, DoppioJVM [2]. One of the challenges of Python is its objects are quite complex/ad-hoc, and can be overridden by the user. I mapped out [3] how I wanted to map Python objects to JavaScript objects, but never had the time to implement it fully. (That document covers Python 2.7; I'm sure there are differences for 3.) It looks like this project has a lot of work to do if it wants to have parity with a native Python VM! But that's part of the fun of writing these things. Best of luck on the VM! If you need a file system to plug into the VM for loading modules/implementing the FS API, do check o