Stream: wasmtime

Topic: How do JCO and componentize-py work?


view this post on Zulip CircuitSacul (Jul 19 2024 at 19:03):

Do these have to include the Python/JavaScript binaries in the final binary in order to work? Is there a lot of overhead here?

view this post on Zulip Ramon Klass (Jul 19 2024 at 20:44):

yes, they both link a whole python/js interpreter into the component. Python components are at least 40MB while jco componenrs are around 8MB I think. with custom quickjs runtime, I could get components that run js under 1MB but that's with taking every shortcut and optimization just to see how small I could get it

unless you have slow internet or low hdd space, this shouldn't be a problem. Though the files are big, loading the bytecode is still very fast

view this post on Zulip CircuitSacul (Jul 19 2024 at 20:52):

Suppose I have 100 different apps written in python that I want to run. Is there a way to share the python/js binary between them, so that it doesn't have to be loaded from my database along with the script?

view this post on Zulip CircuitSacul (Jul 19 2024 at 20:53):

For context, I'm trying to make a platform that lets users write WASM apps. It would be nice if there was a way to make it so that a few supported runtimes (python, js) don't need the user to also upload the whole runtime

view this post on Zulip Chris Fallin (Jul 19 2024 at 20:53):

That's the long-term vision for sure: with graphs of modules in components, one could ideally have one shared (e.g.) spidermonkey.wasm or cpython.wasm that is identical for all JS or Python programs, and somehow deduplicated

view this post on Zulip Chris Fallin (Jul 19 2024 at 20:54):

I know some folks were working on dynamic linking (@Joel Dice and others have thoughts?) but at least in JS we're not quite there yet

view this post on Zulip CircuitSacul (Jul 19 2024 at 21:06):

Thanks, that's exactly what I would need. It's fine if it's not supported yet, but if any languages/versions do support it, I can focus on supporting those first.

Is there a place where added support for this would be announced? Something I can periodically check, or a newsletter, etc.?

view this post on Zulip Chris Fallin (Jul 19 2024 at 21:47):

probably here on this Zulip, potentially on the BA blog if big enough? I know there are some other efforts to do developer-targeted comms e.g. @Bailey Hayes was running a stream for a while. I don't know of any "BA-wide changelog" that would definitely capture this though

view this post on Zulip Christof Petig (Jul 20 2024 at 06:14):

I read that javy uses this technology to reduce binary size, but it might not be fully compatible with components, yet: https://github.com/bytecodealliance/javy?tab=readme-ov-file#creating-and-using-dynamically-linked-modules

JS to WebAssembly toolchain. Contribute to bytecodealliance/javy development by creating an account on GitHub.

view this post on Zulip CircuitSacul (Jul 20 2024 at 12:54):

What’s the difference between javy and jco?

view this post on Zulip Ralph (Jul 20 2024 at 14:24):

different js engines and wasi vs components?

view this post on Zulip Lann Martin (Jul 22 2024 at 13:25):

Chris Fallin said:

That's the long-term vision for sure: with graphs of modules in components, one could ideally have one shared (e.g.) spidermonkey.wasm or cpython.wasm that is identical for all JS or Python programs, and somehow deduplicated

This is already technically possible with Wasmtime and "just" requires an embedding to implement, which is certainly on our collective radar.

view this post on Zulip Jeff Charles (Jul 22 2024 at 13:55):

What’s the difference between javy and jco?

As Ralph alluded to, Javy uses QuickJS while jco uses SpiderMonkey and Javy only supports WASI preview 1 while jco supports the component model. Javy is capable of producing very, very small binaries in the kilobytes range.

view this post on Zulip Joel Dice (Jul 29 2024 at 15:11):

For reference, this is the componentize-py issue about importing a CPython .so file instead of bundling it.

All the basic infrastructure needed to make that work already exists; the main challenge right now is that componentize-py currently relies heavily on build time pre-initialization to execute top-level Python code and retrieve imported dependencies from the filesystem (see https://github.com/bytecodealliance/componentize-py/issues/23). That pre-init step involves modifying the core modules (including the CPython .so) to apply the pre-init snapshot. So we'd need to decide how to package that snapshot in such a way that it can be applied to a stock CPython .so file at instantiation time rather than at build time. I don't foresee any serious issues there, but it will require some effort.

This would dramatically reduce binary sizes in cases where the host can provide these libraries.
Currently, componentize-py "cheats" by assuming all required Python code will be loaded during the component pre-init step, and thus CPython won't need access to any of those files at runtime. This...

Last updated: Dec 23 2024 at 13:07 UTC