Always emit code assuming the GC heap base might be relocated#13165
Always emit code assuming the GC heap base might be relocated#13165alexcrichton merged 2 commits intobytecodealliance:mainfrom
Conversation
Because we lazily allocate the GC heap, it can always do one "move" from null to non-null, even if it cannot move otherwise after that. Also allow specifying `flags = ...` in `.wast` tests. Fixes bytecodealliance#13141 Fixes bytecodealliance#13134
alexcrichton
left a comment
alexcrichton
left a comment
There was a problem hiding this comment.
W.r.t. flags = "..." within *.wast, I'm not opposed but it'll need plumbing through to fuzzing as well where *.wast tests are running with different permutations of flags. That may be relatively difficult to plumb without a sort of "union" operation between to flags-for-config which feels a bit overweight for this. Alternatively though this could be added as a *.wast test and it'll naturally get tested with various permutations of flags, and then this could additionally have a tests/all/*.rs test which sets the specific flags for the regression
| if config.pooling && !flags.is_empty() { | ||
| return Ok(()); | ||
| } |
There was a problem hiding this comment.
The wast pooling logic sets different tunables from the GC heap options, so things start breaking. And there isn't a great way to do the unioning of options because we don't expose getters on wasmtime::Config. I'll just rip that stuff out I guess.
2 participants
Because we lazily allocate the GC heap, it can always do one "move" from null to non-null, even if it cannot move otherwise after that.
Also allow specifying
flags = ...in.wasttests.Fixes #13141
Fixes #13134