[wasm] Don't use SyncTextWriter in single-threaded wasm builds

[kg]

(New description, PR was revised)

We normally wrap custom console streams with SyncTextWriter, which forces the mono interpreter/jit/aot compiler to use synchronized wrappers for all calls through the class. Wrappers have optimization force-enabled, which means all the methods they call get inlined into the wrapper every time, increasing the size of the wrapper's code and the amount of time we spend in codegen for it.

The default wasm configuration right now is single-threaded, so we can skip using SyncTextWriter and as a result skip the synchronized wrapper. While this doesn't fully prevent monitors from becoming involved in startup, it removes a bunch of inlined monitor API calls, which should be an improvement to startup time for any wasm application that touches the console.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[lambdageek]

The fast path should always be taken in ST builds and everything should inline. Why is this necessary?

Also, monitor.isentered will always return false this way

[kg]

The fast path should always be taken in ST builds and everything should inline. Why is this necessary?

Also, monitor.isentered will always return false this way

A sizable percentage of startup time is interp codegen, so I've been seeing how many subtrees of useless methods I can prune out easily.

The monitor.isentered thing is a good point, I guess that rules this optimization out.

[lambdageek]

A sizable percentage of startup time is interp codegen, so I've been seeing how many subtrees of useless methods I can prune out easily.

ah ok. so actually rewriting this part in managed was a bad idea for startup perf. we only measured benchmark (steady state) perf once the interpreter was tiering up the callers. (so Monitor.Enter/Exit loops without contention on ST interp were the same as or a bit faster than the old JIT icall monitor implementation)

[lambdageek]

Do you think it makes sense to use a simpler lockword representation for ST? (for example we don't have to use Interlocked ops to increment/decrement the count - we can just use normal reads/writes). possibly hand-inline more code from ObjectHeader into Monitor.Enter/Exit?

[kg]

Do you think it makes sense to use a simpler lockword representation for ST? (for example we don't have to use Interlocked ops to increment/decrement the count - we can just use normal reads/writes). possibly hand-inline more code from ObjectHeader into Monitor.Enter/Exit?

I think that makes sense, we could just provide simple implementations of the primitives for that configuration which would prune out most of the dependencies without breaking it. I'll make a note to try that.

[kg]

I'm thinking that normal Blazor apps rarely use C# Console. Only our samples do so. Do I understand it right that it would not get triggered unless you actually use it ?

It only gets triggered if you write to the console, yes, but don't we write to the console at least once during startup? I thought I recalled seeing a console message

[kg]

They do use other streams tho, like HTTP stream. Is there similar problem?

This wrapper overhead applies to any synchronized method that is in the startup path, yes

[akoeplinger]

this should use PlatformDetection.IsThreadingSupported too instead of checking for browser so it applies to single-threaded wasi too

[akoeplinger]

this duplicates the conditions from src/mono/System.Private.CoreLib/System.Private.CoreLib.csproj, I don't think we need them here

[akoeplinger]

should also check for WASI