Introduce the javy-profiler-lib crate#1208
Conversation
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.
| use state::State; | ||
| use std::sync::LazyLock; | ||
|
|
||
| // TODO: Passing empty bytes is temporary. Whamm currently does not |
There was a problem hiding this comment.
I am currently working on adding support for this upstream.
|
Hmm, taking a look at the clippy failures, I was not able to repro locally. |
jeffcharles
left a comment
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Nit: I'd prefer if we called this module abstract_interpreter or something similar to disambiguate it.
There was a problem hiding this comment.
I was hoping to raise some VC money with this name. Fixed in 08ae196
I'll add them once I work on the |
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.
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.
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:
br_table)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.
javy-plugin-apiif the QuickJS bytecode has changed.javy-cli,javy-plugin, andjavy-plugin-processingdo not require updating CHANGELOG files.