Use case: indirect jumps in x86 virtualization

[alexp-sssup]

We are currently developing an x86 virtualization solution based on WebAssembly, which is in a fairly advanced stage. It does not seem appropriate to get into details here, but if you want to know more we have presented some details of the JIT architecture at the Wasm SF Meetup back in February: https://www.youtube.com/watch?v=7JUs4c99-mo&t=4s (first 30secs or so of audio are missing. Apologies.)

In our latest post (https://medium.com/leaningtech/extreme-webassembly-1-pushing-browsers-to-their-absolute-limits-56a393435323) we discuss how arbitrary control flow is virtualized and in particular how the efficient implementation of indirect jumps requires tail calls. (And a first public demo of our technology is included)

I wanted to share this information with the community to provide a real use case for Wasm tail calls and possibly spur a discussion about the current state of the implementations and about the timeline for standardization of the feature. I apologize if a repo issue is not the right place for this, suggestions for a more suitable location are welcome.

We plan to release a followup post in a few weeks to detail the limitations we have found in current implementations of tail calls on how these limitations impact the project.

[rossberg]

Thanks for the heads-up, it's appreciated. I believe the only blocker for this proposal to move to the last phase is having a second engine implementing it (besides V8). Perhaps one of the vendors is reading this and can comment on their roadmap. Or you could try to lobby them directly. :)

[alexp-sssup]

In full honesty V8's implementation is also incomplete, we will document our findings in a followup post. None of the two other major engines (Spidermonkey/Firefox and JavaScriptCore/Safari) has done any work on this feature yet, which is a shame.

[binji]

In full honesty V8's implementation is also incomplete

Can you please file bugs at http://crbug.com/v8/new?

[alexp-sssup]

Can you please file bugs at http://crbug.com/v8/new?

I plan to isolate test cases as part of the aforementioned blog post. I will then be able to open reproducible bugs on the tracker. In short: the Liftoff (baseline) compiler does not support tail calls and will silently revert to TurboFan. I also suspect the interpreter mode is buggy, but I need to verify this before bothering you guys with a report.

[backes]

Can you please file bugs at http://crbug.com/v8/new?

I plan to isolate test cases as part of the aforementioned blog post. I will then be able to open reproducible bugs on the tracker. In short: the Liftoff (baseline) compiler does not support tail calls and will silently revert to TurboFan. I also suspect the interpreter mode is buggy, but I need to verify this before bothering you guys with a report.

Thanks for clarifying. No need to open a bug in this case. We are aware that Liftoff support is incomplete, and this is on our list to be fixed. We implement all proposals in TurboFan first, and add Liftoff support later (before shipping, but we were a bit lazy with this in the past and are catching up now). The interpreter is no more, so no worries about that :)

[alexp-sssup]

@binji @backes Understood. Do you guys have a defined timeline for moving this feature from "experimental" to "staging"? It is my understanding that "staging" features are exposed in chrome://flags/ and even just that would make it much simpler to demonstrate our technology to the public.

[backes]

We plan to finish Liftoff support next quarter (Q3 2020). It should be ready to be staged when this is done. Once it is staged, you can enable it via the "Experimental WebAssembly" flag in chrome://flags.

[lin7sh]

it's been staged, well done v8 team! Is there any plan to ship it?

[gahaas]

The plan is to ship it as soon as the proposal reaches stage 4.