December 11, 2024 | JavaScript subgroup (BA Guest Languages SIG)
- Opening, welcome and roll call
- Note: meeting notes linked in the invite.
- Please help add your name to the meeting notes.
- Please help take notes.
- Thanks!
- Announcements
- Submit a PR to add your announcement here
- Other agenda items
- Submit a PR to add your item here
| Attendee |
|---|
| Calvin Preweitt |
| Tomasz Andrzejak |
| Victor Adossi |
| Till Schneidereit |
| Lachlan Heywood |
| Guy Bedford |
| Saul Cabrera |
- HTTP hello world example
- Victor: Ready to go
- Guy: We should discuss how we’re going to update versions
- Maybe add a step to the existing process for updating WASI versions?
- Guy: Test for the new HTTP example?
- Victor: Right now the only test is building, I have a separate PR that adds a
jco servetest, but that’s a bit more involved so will land separately
- Victor: Right now the only test is building, I have a separate PR that adds a
- Guy: Example of how the types map would be huge/important
- Victor: this (along with Resources and how they map) should probably land in the jco repo and also the upstream component book
- Guy: Reference in the jco book, and referenced in the component book
- Victor: this (along with Resources and how they map) should probably land in the jco repo and also the upstream component book
- Guy: Implementation of support for basic well-known WIT worlds would be fantastic
- Two approaches we’ve discussed
- Guy: WebIDL functionality is almost completely documented
- Victor: have an example, but I’m writing it towards a smaller example
- Guy: The important use case is the web platform
- Victor: what about having two examples (one with a smaller)
- Victor: baking the
webidl2witfunctionality into JCO?- Guy: This tooling should probably make it into WIT generation, ideal would be to have maintained packages
- Victor: Create a new upstream
webidl2wit-clicrate? Or add tojco ?- Guy: Ideally the final state of things is people using pre-existing WITs, so let’s have people
cargo installrather than adding tojco
- Guy: Ideally the final state of things is people using pre-existing WITs, so let’s have people
- Victor: have an example, but I’m writing it towards a smaller example
- Victor: Currently adding testing for the JSPI async stuff
- Calvin: Still going to add to the PR and split it up, etc – so still working on this
- Top level resource has landed, but there are still some challenges – some cases where we don’t do enough tracing
- We have function tracing code in
jcothat should be able to do this but it’s split over componentizeJS - Fixed an issue related to import remapping
- bytecodealliance/ComponentizeJS#167
- We can do better on the import management tooling
- Maps all specifiers via internal rewriting, but things can fail – and when they do you get errors at that level
- Guy: Some discussion Victor and I had around arbitrary NodeJS script support spawned some new issues:
- Package support
- NodeJS builtin support in StarlingMonkey
- Native TS support could be a lower level integration (or higher level) in SM
- Till: Someone has actually implemented high quality node resolution support
- Ideally we should do this as much as we can from inside StarlingMonkey, while matching Deno largely
- There are good reasons to run without a separate componentization step
- The more we can stuff into the runtime the better
- Guy: Agreed, SM should be able to handle the full ecosystem expectations for running JS – we should probably avoid doing more pre-processing in ComponentizeJS
- Till: Where feasible!
- Victor: I was thinking a little bit about this and if I was going to do it at the above-StarlingMonkey level I’d probably just use Rollup as a library there where possible?
- Guy: Approach we use in SM is just running the JS in the engine itself
- Till: What we could do here is modify the module loader which works on any file loaded (ignoring script mode)
- We load it, look at all it’s imports then recursively trigger module loading
- We could hook in a transform step here (i.e. load a TS file and translate it on the fly)
- We don’t have to teach SM to run TS code, the JS engine just sees JS code, but as part of loading we would translate on a per-module basis
- Worth looking at how Deno does it (they may hook into
eval())
- Worth looking at how Deno does it (they may hook into
- In workflow for build & deploy use case, we wouldn’t need a bundler (though they are useful for tree-shaking/other optimization)
- Effectively, componentization is bundling, so this is related
- Guy: One nice thing is that we don’t need source maps – will have the original sources.
- Guy: One concern is the the TS compiler is XMB
- Till:
swcproject might be a decent option here, with some types-stripping functionality? Deno isn’t bundlingtsc, are they? - Guy: It should be possible to directly depend on the NodeJS version of projects like
swc– hopefully there is the ability to DCE between use Wizer. - Till: We could probably cut the size of StarlingMonkey by half if we remove stuff that’s not used (the WebAssembly built-in machinery that we’ll never use)
- There is a lot of dead weight that could be eliminated
- Till:
- Till: What we could do here is modify the module loader which works on any file loaded (ignoring script mode)
- Guy: Landed Tomasz’s PR for blob support
- bytecodealliance/StarlingMonkey#177
- Tomasz: Also started looking at foreign data
- Till: Reviewed the File API PR today, realized that some builtins, found it very hard to connect the files back to the spec, hard to assess how to well it conformed the spec – will add these things
- Till: Noting Tomasz’s issues with Inheritance
- Till: This is the first time this is coming up
- Quick answer is that in
JSInitClasspassing in the pointer should get you the inheritance chain but it doesn’t make the instance work - In C++ all the methods are static methods on a C++ class with many instance checks/asserts at the , with instances implemented in a base class for the builtins.
- The only way I know of to make that properly work is to overwrite the
isInstanceimpl inBlobto check whether things are blobs or files. - To have that be safe, all the slots need to be identical (all slots used by Blob need to be preserved for the usage of File), Request and Response serve as an example of this.
- They’re represented by Mixins, and “body owners”, and because of that there’s an abstracted-out base class which defines many slots. The child classes will then add to the slots of the base classes.
- C++ classes that operate on blobs can also operate on File instances and whatever you need can be inside the file class.
- Till: Thanks for the help on the interest management
- Guy: There’s interest until something responds
- Updated Fastly’s implementation of the interest machinery, ran into some weird bug
- Even when there is no change , a response streaming test fails
- Possibly ordering related
- Will pair with Tomasz on this later and hopefully we can make progress
- Guy: Optimization stuff, we’d like to ship the i18n, blocked on Wasi SDK upgrade, might be lucky and the blobs
- Till: First instinct is to disable wasm-opt
- Guy: Only happens in release builds…
- Till: Still worth doing in the release build just in case, but could be dangling memory, possibly changing access patterns + garbage?
- Guy: Seeing full response , so it’s not garbage, but it’s as if the framing header feature isn’t on, but the host call is happening. Maybe stream is going out before host call? Event loop refactoring? Content length header not being set properly?
- Tomasz: Mention of GCC plugin for static analysis? Also a flag to increase GC activity for testing? Would we want to bring this to StarlingMonkey?
- Till: The latter makes sense for GC debugging – you can go all the way up to GCing before/after every allocation (with possibly rewriting with a garbage pattern)
- GCC plugin would be exceptionally nice, but it’s a GCC plugin and ther eis no Wasm backend for GCC nor the ability to compile SM
- There’s also an Address sanitizer for use with we could look into
- Till’s Demo: Debugging a fetch handler with a breakpoint and live reloading with StarlingMonkey, with callstack
- Guy: Repl support?
- Till: Not yet! Also doesn’t support CompnentizeJS yet
- Does support live-reloading but doesn’t do a componentize step in between yet, instead it starts a
wasmtimeprocess with the component (starling.wasmwithout any content) and sets up a socket connection to talk DAP, it instructs loading files (possibly new on each request)
- Till: To make this work with componentizeJS we need to add a generate-bindings-but-dont-eval-content mode
- Guy: ComponentizeJS does use internal modules, so in-theory there could be a well named scheme for the bindings
- Guy: Repl support?