Remove Windows-specific code for static memory bounds

[alexcrichton]

Added in c4e1022 I think the original
reason (which I'm not entirely knowledgeable of) may no longer be
applicable? In any case this is a significant difference on Windows from
other platforms because it makes loads/stores of wasm code have manual
checks instead of relying on the guard page, causing runtime and
compile-time slowdowns on Windows-only.

I originally rediscovered this when investigating #2318 and saw that
both the compile time of the module in question and trap information
tables were much larger than they were on Linux. Removing this
Windows-specific configuration fixed the discrepancies and afterwards
Linux and Windows were basically the same.

[alexcrichton]

cc @sunfishcode and @peterhuene, I'm not sure whether this is still needed any more, but I'm curious if y'all know more!

[whitequark]

causing runtime and compile-time slowdowns on Windows-only.

Oh huh, so I wasn't imagining the slowdown! Thanks for fixing it.

[github-actions]

Subscribe to Label Action

cc @peterhuene

Details

This issue or pull request has been labeled: "wasmtime:api"

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 .github/subscribe-to-label.json configuration file.

Learn more.

[peterhuene]

I don't know the background to the original change as it was unfortunately before my time.

As it is referencing the page file, all I can think of is that the Windows implementation was originally allocating the memory committed instead of reserved?

I think that was the case given this old code.

[peterhuene]

Let's let @sunfishcode weigh-in before merging this as he originally added this restriction.

[sunfishcode]

Looks good to me! We have much better Windows support and testing now than we did at that time, so now if we ever run out of resources, we're in a much better position now to find it and understand what's happening.