Stream: StarlingMonkey

Topic: starlingmonkey-ng + weval

Tomasz Andrzejak (Jul 02 2026 at 15:57):

Hey,

I have a mozjs branch with weval patches and IC corpus rebuild here:

https://github.com/andreiltd/mozjs/tree/weval

There are 5 commits added on top of current mozjs patches:

• dropped the old SpiderMonkey JS streams patches -- starling uses builtin implementation outside SpiderMonkey,
• added an opt-in SpiderMonkey  JS  shell build to  mozjs-sys ,
• ported Chris PBL/weval annotation,
• added IC corpus rebuild script that builds collection/validation shells and uses firefox checkout only for test harnesses (jstests, jit-tests),
• rebuilt and committed the IC corpus using script above.

It's hard to test end-to-end without componentization implementation in place but hopefully this patches will be useful very soon.

One thing worth clarifying up front is how the componentization pipeline works in starlingmonkey-ng, and where  weval  should fit into it.

My assumption is that you’ll be running  wizer  on a component rather than on a core module. If that’s the case, simply replacing  wizer  with  weval  likely won’t work. Ideally, we should add component support to weval  so it can operate at the same point in the pipeline.

Till Schneidereit (Jul 03 2026 at 14:22):

very nice, thank you! :heart:

Yes, we'll need to add component support to weval, unfortunately: we'll not be using wasip1 calls at all in -ng, so a non-component approach couldn't possibly work. Is that something you'd be up for working on as well?

Tomasz Andrzejak (Jul 03 2026 at 14:31):

Hey, yeah, I will allocate some time to work on that next week. My plan for that would be to just copy whatever wizer is doing for components to weval. I assume Chris will be onboard with supporting components in weval? (I won't ping him here, I think he's on vacation).

Till Schneidereit (Jul 03 2026 at 15:11):

I'd be very surprised if Chris was opposed to this idea :slight_smile:

Chris Fallin (Jul 03 2026 at 15:40):

(ghost-of-cfallin appears [yes, need to work on my PTO discipline]: absolutely we should support components in weval. weval uses wizer as a library to get the snapshot that it then operates on; with a component snapshot, one would need to pull it apart into core modules, find the relevant one, then process that with the translate-to-IR-with-waffle / p-eval / re-compile flow, then put the component back together. lots of plumbing but nothing fundamentally hard AFAICS)

Tomasz Andrzejak (Jul 06 2026 at 08:48):

Hey, @Till Schneidereit , I wanted to clarify one more thing: how do you plan to use wizer in starlingmonkey-ng: cli or lib API? Currently weval is cli only, would that be an issue?

Till Schneidereit (Jul 06 2026 at 09:40):

Hmm, good question. I think it might be an issue, because the integration will look a bit different. If it's not somehow very difficult to do, support lib use for weval would be good, I think

Chris Fallin (Jul 06 2026 at 17:40):

that seems like a pretty simple refactor to weval's toplevel -- the core is really a function weval(CoreModule) -> CoreModule so if an existing library user is doing the wizening, all it needs to do is pull out the right core module and give it to weval via that API

Tomasz Andrzejak (Jul 06 2026 at 18:27):

I have component support pretty much implemented now, but it needs some more testing. I will have PR tomorrow and then I can refactor the lib.

Tomasz Andrzejak (Jul 07 2026 at 17:26):

https://github.com/bytecodealliance/weval/pull/31

Last updated: Jul 29 2026 at 05:03 UTC