Fuzzer: Adjust parameters by input size, sometimes#7276
Fuzzer: Adjust parameters by input size, sometimes#7276kripken merged 12 commits intoWebAssembly:mainfrom
Conversation
| // A typical random wasm input from fuzz_opt.py is fairly large (to minimize | ||
| // the process creation overhead of all the things we run from python), and | ||
| // the defaults are tuned to that. | ||
| double size = random.remaining(); |
There was a problem hiding this comment.
Why does random.remaining() correspond to the input size? This seems non-obvious, so perhaps is worth a comment.
There was a problem hiding this comment.
I added a comment. We didn't read anything yet, so the remaining is the initial.
| // the process creation overhead of all the things we run from python), and | ||
| // the defaults are tuned to that. | ||
| double size = random.remaining(); | ||
| const double MEAN_SIZE = 40 * 1024; |
There was a problem hiding this comment.
Is this number taken from measurements? Do we expect it to change much over time? (Not that it would matter much if it did.)
There was a problem hiding this comment.
This corresponds to the mean size from fuzz_opt.py. I added a comment.
|
|
||
| auto bits = random.get(); | ||
| if (bits & 1) { | ||
| fuzzParams->MAX_NEW_GC_TYPES = fuzzParams->MAX_NEW_GC_TYPES * ratio; |
There was a problem hiding this comment.
Can we use *= ratio here and below?
There was a problem hiding this comment.
Done. For some reason I thought int *= double might coerce the rhs to int first...
| // Only increase the number of tries. Trying fewer times does not help | ||
| // find more interesting patterns. | ||
| if (ratio > 1) { | ||
| fuzzParams->TRIES = fuzzParams->TRIES * ratio; |
There was a problem hiding this comment.
Can we give TRIES a more descriptive name?
There was a problem hiding this comment.
Hmm, I can't think of one. This is "number of tries we make, when we have something that might work or might fail". What do you suggest?
2 participants
Rather than always have a fixed max of heap types, globals, etc. allow more if the
input size is large. This adds variety.
There is a cost to this variety, we go from 0.89% ignored runs to 1.1% (that is,
slightly more runs contain something that prevents us from doing the work
we want, like hitting a host limitation or seeing the testcase just traps). This
increase seems small enough to be reasonable, and we only do this half the
time, so the old behavior is still being tested at half throughput.