github-actions[bot] commented on issue #6835:
Subscribe to Label Action
cc @peterhuene
<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config"Thus the following users have been cc'd because of the following labels:
- peterhuene: wasmtime:api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
github-actions[bot] commented on issue #6835:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[ ] If you added a new
Config
method, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[ ] If you added a new
Config
method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config
][fuzzing-config] (or one
of its nestedstruct
s).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
github-actions[bot] commented on issue #6835:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "fuzzing", "wasmtime:docs"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
fitzgen commented on issue #6835:
Alex is out of office till the end of the week; do you think you could take a look at this @cfallin?
cfallin commented on issue #6835:
Alex is out of office till the end of the week; do you think you could take a look at this @cfallin?
I can possibly take a look, but I'm dealing with pretty bad wrist RSI right now and trying to learn to use my machine with voice dictation so it might take quite a lot of time. if it can wait until Alex is back maybe that's better...
jameysharp commented on issue #6835:
The first two commits in this PR are tiny enough that I've just reviewed them and would be happy to sign off on them. Unfortunately the third PR is the interesting part and is a little more overwhelming, and I can't say much about it yet.
On a brief skim I can at least say that moving
MemoryAllocationIndex
intowasmtime_runtime::Memory
like you suggest would remove a bunch of changes which just add.1
into various places. (Similarly for table allocations, I assume?) I don't know what other impact that would have so I'm not sure why you didn't go with that option to begin with.The other thing that jumps out at me is that extracting
MemoryPool
/TablePool
/StackPool
to separate modules looks like it might be easy to split out as a separate PR to reduce the amount of churn in this commit.
cfallin commented on issue #6835:
I'd be happy to do a live review over Zoom if that would help... I'm just awfully slow at typing right now!
fitzgen commented on issue #6835:
FWIW, 25 instantiation benchmarks "improved", while 9 "regressed". I think this is basically all within the noise.
<details>
sequential/default/data_segments.wat time: [16.207 µs 16.300 µs 16.396 µs] change: [-14.937% -13.832% -12.750%] (p = 0.00 < 0.05) Performance has improved. Found 4 outliers among 100 measurements (4.00%) 1 (1.00%) high mild 3 (3.00%) high severe sequential/pooling/data_segments.wat time: [4.1824 µs 4.2111 µs 4.2460 µs] change: [-1.4282% +0.2191% +1.7369%] (p = 0.79 > 0.05) No change in performance detected. Found 7 outliers among 100 measurements (7.00%) 4 (4.00%) high mild 3 (3.00%) high severe parallel/default/data_segments.wat: with 1 thread time: [16.374 µs 16.470 µs 16.579 µs] change: [-12.172% -10.245% -8.4601%] (p = 0.00 < 0.05) Performance has improved. Found 13 outliers among 100 measurements (13.00%) 7 (7.00%) high mild 6 (6.00%) high severe parallel/default/data_segments.wat: with 2 threads time: [22.580 µs 22.767 µs 22.995 µs] change: [-9.2143% -7.3138% -4.8914%] (p = 0.00 < 0.05) Performance has improved. Found 11 outliers among 100 measurements (11.00%) 6 (6.00%) high mild 5 (5.00%) high severe parallel/default/data_segments.wat: with 3 threads time: [32.501 µs 32.825 µs 33.211 µs] change: [-5.8662% -3.5161% -0.8508%] (p = 0.01 < 0.05) Change within noise threshold. Found 16 outliers among 100 measurements (16.00%) 5 (5.00%) high mild 11 (11.00%) high severe parallel/default/data_segments.wat: with 4 threads time: [55.409 µs 56.588 µs 57.990 µs] change: [-6.6418% -3.2057% +0.3236%] (p = 0.08 > 0.05) No change in performance detected. parallel/pooling/data_segments.wat: with 1 thread time: [4.2061 µs 4.2405 µs 4.2806 µs] change: [-0.5488% +1.1592% +2.8516%] (p = 0.17 > 0.05) No change in performance detected. Found 11 outliers among 100 measurements (11.00%) 9 (9.00%) high mild 2 (2.00%) high severe parallel/pooling/data_segments.wat: with 2 threads time: [4.9711 µs 5.0071 µs 5.0478 µs] change: [+0.0367% +1.6271% +3.1874%] (p = 0.05 < 0.05) Change within noise threshold. Found 9 outliers among 100 measurements (9.00%) 6 (6.00%) high mild 3 (3.00%) high severe parallel/pooling/data_segments.wat: with 3 threads time: [5.5409 µs 5.6522 µs 5.8000 µs] change: [+2.4451% +7.1764% +11.976%] (p = 0.00 < 0.05) Performance has regressed. Found 15 outliers among 100 measurements (15.00%) 7 (7.00%) high mild 8 (8.00%) high severe parallel/pooling/data_segments.wat: with 4 threads time: [6.0691 µs 6.3499 µs 6.7057 µs] change: [-1.7330% +7.2518% +17.575%] (p = 0.13 > 0.05) No change in performance detected. Found 20 outliers among 100 measurements (20.00%) 20 (20.00%) high severe deserialize/deserialize/data_segments.wat time: [33.431 µs 33.809 µs 34.249 µs] change: [+1.4039% +3.1953% +5.1095%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 3 (3.00%) high mild 9 (9.00%) high severe deserialize/deserialize_file/data_segments.wat time: [31.674 µs 31.989 µs 32.413 µs] change: [-1.6587% +0.5155% +3.0517%] (p = 0.66 > 0.05) No change in performance detected. Found 13 outliers among 100 measurements (13.00%) 1 (1.00%) high mild 12 (12.00%) high severe sequential/default/empty.wat time: [2.8884 µs 2.9012 µs 2.9153 µs] change: [-13.844% -8.4599% -3.6245%] (p = 0.00 < 0.05) Performance has improved. Found 6 outliers among 100 measurements (6.00%) 2 (2.00%) high mild 4 (4.00%) high severe sequential/pooling/empty.wat time: [2.9106 µs 2.9333 µs 2.9626 µs] change: [-4.1436% -1.5437% +1.6409%] (p = 0.30 > 0.05) No change in performance detected. Found 13 outliers among 100 measurements (13.00%) 3 (3.00%) high mild 10 (10.00%) high severe parallel/default/empty.wat: with 1 thread time: [2.9121 µs 2.9299 µs 2.9504 µs] change: [+1.0205% +2.5318% +4.2334%] (p = 0.00 < 0.05) Performance has regressed. Found 17 outliers among 100 measurements (17.00%) 10 (10.00%) high mild 7 (7.00%) high severe parallel/default/empty.wat: with 2 threads time: [3.2615 µs 3.3018 µs 3.3505 µs] change: [+1.9848% +3.3641% +4.8919%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 14 (14.00%) high severe parallel/default/empty.wat: with 3 threads time: [3.4042 µs 3.4264 µs 3.4529 µs] change: [+1.3432% +3.2608% +5.7222%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 5 (5.00%) high mild 8 (8.00%) high severe parallel/default/empty.wat: with 4 threads time: [3.5997 µs 3.7497 µs 3.9238 µs] change: [-2.5449% +3.1724% +8.8255%] (p = 0.29 > 0.05) No change in performance detected. Found 18 outliers among 100 measurements (18.00%) 1 (1.00%) high mild 17 (17.00%) high severe parallel/pooling/empty.wat: with 1 thread time: [2.9411 µs 2.9568 µs 2.9740 µs] change: [-6.8359% -4.3504% -2.0078%] (p = 0.00 < 0.05) Performance has improved. Found 8 outliers among 100 measurements (8.00%) 4 (4.00%) high mild 4 (4.00%) high severe parallel/pooling/empty.wat: with 2 threads time: [3.2878 µs 3.3114 µs 3.3471 µs] change: [-12.572% -10.707% -9.0176%] (p = 0.00 < 0.05) Performance has improved. Found 6 outliers among 100 measurements (6.00%) 3 (3.00%) high mild 3 (3.00%) high severe parallel/pooling/empty.wat: with 3 threads time: [3.4820 µs 3.5166 µs 3.5603 µs] change: [-11.531% -8.9122% -6.6623%] (p = 0.00 < 0.05) Performance has improved. Found 9 outliers among 100 measurements (9.00%) 4 (4.00%) high mild 5 (5.00%) high severe parallel/pooling/empty.wat: with 4 threads time: [3.6409 µs 3.7537 µs 3.8965 µs] change: [-16.527% -11.957% -6.6742%] (p = 0.00 < 0.05) Performance has improved. Found 19 outliers among 100 measurements (19.00%) 6 (6.00%) high mild 13 (13.00%) high severe deserialize/deserialize/empty.wat time: [30.528 µs 30.743 µs 31.004 µs] change: [-2.9185% -0.4947% +1.5731%] (p = 0.68 > 0.05) No change in performance detected. Found 6 outliers among 100 measurements (6.00%) 4 (4.00%) high mild 2 (2.00%) high severe deserialize/deserialize_file/empty.wat time: [31.130 µs 31.350 µs 31.596 µs] change: [-1.4528% -0.2984% +0.7568%] (p = 0.62 > 0.05) No change in performance detected. Found 6 outliers among 100 measurements (6.00%) 5 (5.00%) high mild 1 (1.00%) high severe sequential/default/spidermonkey.wasm time: [17.126 µs 17.343 µs 17.598 µs] change: [-24.108% -23.194% -22.072%] (p = 0.00 < 0.05) Performance has improved. Found 5 outliers among 100 measurements (5.00%) 2 (2.00%) high mild 3 (3.00%) high severe sequential/pooling/spidermonkey.wasm time: [5.6331 µs 5.6638 µs 5.6966 µs] change: [-4.0009% -2.8480% -1.6732%] (p = 0.00 < 0.05) Performance has improved. Found 6 outliers among 100 measurements (6.00%) 3 (3.00%) high mild 3 (3.00%) high severe parallel/default/spidermonkey.wasm: with 1 thread time: [17.304 µs 17.442 µs 17.610 µs] change: [-23.116% -20.805% -18.284%] (p = 0.00 < 0.05) Performance has improved. Found 12 outliers among 100 measurements (12.00%) 2 (2.00%) high mild 10 (10.00%) high severe parallel/default/spidermonkey.wasm: with 2 threads time: [31.028 µs 31.269 µs 31.553 µs] change: [-1.1847% +0.3038% +1.7367%] (p = 0.68 > 0.05) No change in performance detected. Found 8 outliers among 100 measurements (8.00%) 6 (6.00%) high mild 2 (2.00%) high severe parallel/default/spidermonkey.wasm: with 3 threads time: [39.188 µs 39.735 µs 40.395 µs] change: [-14.835% -12.205% -9.7141%] (p = 0.0 [message truncated]
fitzgen edited a comment on issue #6835:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[x] If you added a new
Config
method, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[ ] If you added a new
Config
method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config
][fuzzing-config] (or one
of its nestedstruct
s).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
fitzgen edited a comment on issue #6835:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[x] If you added a new
Config
method, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[x] If you added a new
Config
method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config
][fuzzing-config] (or one
of its nestedstruct
s).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
fitzgen edited a comment on issue #6835:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[x] If you added a new
Config
method, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[x] If you added a new
Config
method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config
][fuzzing-config] (or one
of its nestedstruct
s).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[x] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
Last updated: Dec 23 2024 at 13:07 UTC