Add PoolingAllocatorMetrics

[lann]

This exposes some basic runtime metrics derived from the internal state of a PoolingInstanceAllocator.

Two new atomics were added to PoolingInstanceAllocator: live_memories and live_tables. While these counts could be derived from existing state it would require acquiring mutexes on some inner state.

Fixes #11449

[lann]

I was on the fence about using Ordering::Relaxed for these, but if someone ends up using metrics in actual business logic (like server backpressure) it would be a pretty nasty surprise for these to underflow...

[alexcrichton]

I'd actually opt towards using Relaxed here since there's explicitly no data dependency with anything else in the system (e.g. this isn't looking for memory effects of another operation or publishing its own memory effects). Could you detail more about the underflow point though? How would atomic ordering affect that?

[lann]

Sounds good. I don't really have a good grasp of relaxed atomic semantics so I just pessimistically assume that a concurrent thread would be able to go back in time and kill its own grandparent or whatever.

[alexcrichton]

Heh nah makes sense. I'm by no means an expert but I'm confident enough in my understanding that if atomics are used for things like metric purposes it's fine to use relaxed. Relaxed ordering, AFAIK, basically means that you get no guarantees about other memory locations in the program when you observe a value. For the memory location in question, though, everything is still just as atomic as you'd expect (e.g. fetch-and-add still does that, it doesn't like switch to non-atomics). This happens because relaxed atomics can be reordered around each other by the compiler, so you can't for example say "I saw N memories in use, therefore I must see N+1 tables in use next", that's not valid.

[lann]

Yeah makes sense. I guess I'm not entirely clear on what makes increment_component_instance_count different here (above) that it would need AcqRel?

[alexcrichton]

Oh it's not, the main difference is I saw this here and no one saw it there most likely. There's no need for that to use AcqRel either and IMO it should also be using Relaxed

[alexcrichton]

I'd actually opt towards using Relaxed here since there's explicitly no data dependency with anything else in the system (e.g. this isn't looking for memory effects of another operation or publishing its own memory effects). Could you detail more about the underflow point though? How would atomic ordering affect that?

[alexcrichton]

While the vet error is spurious, the miri failure looks legitimate.

[lann]

This does indeed fail under miri locally:

wasmtime/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/metrics.rs

Lines 76 to 77 in fc3f429

	Engine::new(&Config::new().allocation_strategy(InstanceAllocationStrategy::pooling()))
	.unwrap();

Presumably I can work around this by overriding some default config, but is it a bug that the defaults don't work with miri?

[lann]

Oh well I guess that's pretty straightforward:

wasmtime/crates/environ/src/tunables.rs

Lines 149 to 150 in fc3f429

	if cfg!(miri) {
	Tunables::default_miri()

Any preference on how to fix this?

• Add a cfg!(miri) for default max_memory_size
• Just set max_memory_size in the test

[alexcrichton]

The main test suite has a helper function for a "small pool config" which could be modeled here as well, but this test isn't too interesting for miri so it's also fine to slap a #[cfg_attr(miri, ignore)] on the test