Remove the limitation on the number of concurrently running mutators

[mraleph]

We should decide what we want to do with the currently existing limitation on the number of concurrently running mutators.

We should either make it more known (e.g. document it) or we should remove it.

We could even add a runtime warning: when we are trying to enter isolate as a mutator and are waiting for too long due to the limit on the number of mutators - we should consider reporting this error.

I don't think the limitation itself is all that bad for mobile usages - because it does not make sense to spawn so many concurrently running isolates anyway, but it might be causing real issues to server side / batch uses of Dart.

/cc @mkustermann @aam @rmacnak-google @a-siva

[mkustermann]

There's a set of different aspects we can document

• Semantically one can run only into trouble if N>limit isolates try to synchronously communicate with each other (e.g. by stepping out of the pure Dart safety zone with FFI)
• If one stays in the pure isolates world: isolates communicate via message passing and run async code / often yield to event loop (which is needed to e.g. receive messages), then there's no risk of deadlocks etc. One can have thousands of isolates in that case.
• A dart program cannot take advantage of more cores than this limit. Though as a language focused more on the client-side, it's currently also not a goal to scale to 100s of cores.
• If there's oversubscription: more isolates want to run than the limit, they do schedule round-robin and we're not guaranteed to distribute CPU fairly among them. If there's no oversubscription (number if isolates ready to run is less that the limit), then we run all ready isolates in parallel and OS distributes CPU cycles (hopefully fairly) among them.

[mraleph]

A dart program cannot take advantage of more cores than this limit. Though as a language focused more on the client-side, it's currently also not a goal to scale to 100s of cores.

It might not be goal to scale to 100s of cores, but neither it is a goal to make it impossible to discover why you hit a scalability issue.

We would like to see Dart used more and more outside of client-side context - so it makes sense to avoid adding hidden limitations like this or at least make them easier to discover.

[mkustermann]

@mraleph Yes, the list I wrote above is what we can/should document. We can of course phrase it differently and just point out it's due to a technical limitation.

[parlough]

\cc @ericwindmill Just so you're aware of the discussion and possibilities here :) - Perhaps you have some thoughts too!

[mraleph]

I would like to repurpose this issue to investigate if we could simply lift this limitation. So I am retitling this accordingly.

[blakeAspentech]

@rmacnak-google , I posted about this with a reproduction over on the flutter repo. I see that your commit says it resolves this issue, but it was only committed last week. Is there a version of flutter/dart that I can switch to to verify your fix on my example repo?