Skip to content

Introduce the javy-profiler-lib crate#1208

Merged
saulecabrera merged 4 commits into
bytecodealliance:mainfrom
saulecabrera:grp-lib
May 14, 2026
Merged

Introduce the javy-profiler-lib crate#1208
saulecabrera merged 4 commits into
bytecodealliance:mainfrom
saulecabrera:grp-lib

Conversation

@saulecabrera
Copy link
Copy Markdown
Member

Part of #1206

This is the first change towards a Wasm-native profiler for Javy generated modules.

Particularly, this change introduces the profiler library crate, which will be used as a user-provided library by
Whamm.

The library will be compiled to wasm32-wasip1 and will have the following responsibilities:

  • Detecting the Wasm function in the target app holding the interpreter dispatch loop
  • Detecting the byte-load provenance used to dispatch to the next opcode (index argument to br_table)
  • Holing the necessary state to construct the JS execution trace
  • Generating the execution trace output for analysis

This change includes, point 1 and 2. The remaining functionality will be done in separate pull requests.

Note that, as stated in the issue above, this work is deemed experimental for the time being and this crate will be included through a feature flag when added to the CLI.

  • I've updated the default plugin import namespace and incremented the major version of javy-plugin-api if the QuickJS bytecode has changed.
  • I've updated the relevant CHANGELOG files if necessary. Changes to javy-cli, javy-plugin, and javy-plugin-processing do not require updating CHANGELOG files.
  • I've updated the relevant crate versions if necessary. Versioning policy for library crates
  • I've updated documentation including crate documentation if necessary.

Part of bytecodealliance#1206

This is the first change towards a Wasm-native profiler for Javy
generated modules.

Particularly, this change introduces the profiler library crate, which
will be used as a user-provided library by
[Whamm](https://github.com/ejrgilbert/whamm).

The library will be compiled to wasm32-wasip1 and will have the
following responsibilities:

* Detecting the Wasm function in the target app holding the interpreter dispatch loop
* Detecting the byte-load provenance used to dispatch to the next
opcode (index argument to `br_table`)
* Holing the necessary state to construct the JS execution trace
* Generating the execution trace output for analysis

This change includes, point 1 and 2. The remaining functionality will
be done in separate pull requests.

Note that, as stated in the issue above, this work is deemed
experimental for the time being and this crate will be included
through a feature flag when added to the CLI.
@saulecabrera saulecabrera requested a review from jeffcharles May 12, 2026 17:49
use state::State;
use std::sync::LazyLock;

// TODO: Passing empty bytes is temporary. Whamm currently does not
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am currently working on adding support for this upstream.

@saulecabrera
Copy link
Copy Markdown
Member Author

Hmm, taking a look at the clippy failures, I was not able to repro locally.

Copy link
Copy Markdown
Collaborator

@jeffcharles jeffcharles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add some docs somewhere about how this will integrate with Whamm and other pieces? I understand if it makes more sense to add that later as part of a future PR.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I'd prefer if we called this module abstract_interpreter or something similar to disambiguate it.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hoping to raise some VC money with this name. Fixed in 08ae196

@saulecabrera
Copy link
Copy Markdown
Member Author

saulecabrera commented May 14, 2026

Can you add some docs somewhere about how this will integrate with Whamm and other pieces? I understand if it makes more sense to add that later as part of a future PR.

I'll add them once I work on the javy-profiler crate, which will add the integration with Whamm.

@saulecabrera saulecabrera merged commit 29da3d2 into bytecodealliance:main May 14, 2026
4 checks passed
@saulecabrera saulecabrera deleted the grp-lib branch May 14, 2026 11:11
saulecabrera added a commit to saulecabrera/javy that referenced this pull request Jun 2, 2026
This patch is a follow-up to
bytecodealliance#1208.

It marks the initial work to introduce the profiling functionality as
described in bytecodealliance#1206.

Concretely, this patch focuses on the Whamm integration:

* Making the necessary changes to the build system to enable building
the profiler library that will be consumed by Whamm.
* Adding a new `profile` command and `profile inject` subcommad to the
CLI
* Gating this functionality under a feature flag.

Structure wise I tried to make this change as self-contained as
possible (see the changes the makefile, and the introduction of the
`profiler` feature flag), allowing for an straightforward removal
from tree if we ever decide that this feture should not stabilized.
saulecabrera added a commit to saulecabrera/javy that referenced this pull request Jun 2, 2026
This patch is a follow-up to
bytecodealliance#1208.

It marks the initial work to introduce the profiling functionality as
described in bytecodealliance#1206.

Concretely, this patch focuses on the Whamm integration:

* Making the necessary changes to the build system to enable building
the profiler library that will be consumed by Whamm.
* Adding a new `profile` command and `profile inject` subcommad to the
CLI
* Gating this functionality under a feature flag.

Structure wise I tried to make this change as self-contained as
possible (see the changes the makefile, and the introduction of the
`profiler` feature flag), allowing for an straightforward removal
from tree if we ever decide that this feture should not stabilized.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants