Hi Eliot,
You have nothing to worry about, for now :)
Just to give you an idea, in order to get reasonable results in the test runner, I have increased the timeout 10 fold and I still get some of the tests timing out.
But, while I did try to be mindful about performance, I did not try to optimize for testing - I suspect there is a lot of low hanging fruit in the reflection area that could make the tests run faster. Anyway, general responsiveness is very good, so it is a perfectly usable environment. I think that, after addressing the development environment/reflection areas, further performance improvements would require type inferencing/inlining, which would come with significant complications re de-optimization if you want to preserve Smalltalk's flexible nature - but they would work well for packaged applications that do not require that level of flexibility.
On the other hand, it is nice to be able to just sit back and let the cohorts of developers at Google work on improving performance for you :)
Regarding thisContext, some of the commonly used patterns, like String>>translated, Object>>deprecated or Object>>mustBeBoolean are handled at (JavaScript source) code generation time.
Since we already have for free a (JavaScript) source-level debugger and profiler in the browser (or Node), there is no need for a context/stack-walking based debugger or profiler.
For odd usages, thisContext translates to the instantiation of a Context object which just has its method/block and receiver populated, thus returning nil for sender.
Exceptions are handled specially, see below.
This seems to cover "normal" images pretty well, but other specific scenarios could be covered with similarly specialized solutions.
With processes I, I first made a half-hearted attempt to generate continuation-passing style JavaScript source code, but this looked like it was going to have horrible performance, so I tried to combine it with some type specializations (something like inline caches, but in the source JavaScript). This in turn lead to horrendous/unreadable/undebuggable code (to be fair even the straight CPS code was quite hard to read and very different from the original Smalltalk), so I dropped it. It was a fun exercise though :).
Then I had the revelation that I could use JavaScript's yield* (iterating yield) for invocations, using the generators' stacks as the processes' stacks, and this turned out to work pretty well, as Chrome's optimizer seems to be dealing with it just fine (occasionally while debugging I can see that the JavaScript engine is inlining some of the calls). All the methods are defined as generator functions, and they are all invoked via yield* (other than #class and #==). The scheduler is a loop that just invokes the current processes' block (which is also a generator function) next() function, and the process/semaphore primitives use real (non-iterating) yield to pass the baton back to the scheduler loop and on to the next process.
non-local return is using a top-level try/catch in the methods needing it, where the catch identity matches the NonLocalReturn exception instantiated for the method (and thrown from the closure) to perform a normal method return or rethrow.
At generation time I am also optimizing away some of them for well known patterns like at:..ifAbsent:[^...] or detect:..ifNone:[^...]
unwind protect is also using JavaScript level try/finally or try/catch constructs.
exception handling is performed by reifying (just) the handlers (instead of all the contexts chain) associated with a process. Smalltalk-level signal is not a JavaScript throw, it is a loop within the handlers, plus a try/catch to handle resume (resuming is a JavaScript throw). Unwinding is a JavaScript throw. Primitive 199 is not just a marker, but an installer for new handlers, a loop (for retries) and a try/catch to handle local exit from the handler block.
All the best,
Florin