Revisit the threading mechanisms behind parallelism inside GAMA

[AlexisDrogoul]

With the advent of virtual threads, Java offers an interesting way to envision the parallelism between agents in GAMA. Right now, the mechanisms rely on the use of a ForkJoinPool limited by the number of cores available in the platform (or the max. allowed by the user). Chunks of agents are executed using ForkJoinTasks dispatched to the different threads. It is quite efficient but suffers from different drawbacks, among them the impossibility to "pin" an agent to a thread (and for instance to effectively use ThreadLocal variables inside agents), which explains why we had to have a slightly different mechanisms for running simulations so that they remain "pinned" to one and only one thread.

Virtual threads are using the same kind of mechanism under the hood : a ForkJoinPool of platform threads (called the "carrier threads") are used to host and run the virtual threads. The interesting thing is that they are extremely lightweight and that the ThreadLocal approach can be used quite effectively to preserve the state of agents (for example when running a skill or other executables, even though most of them are singletons).

So it could be interesting to explore an approach where one agent = one (virtual) thread, as it might have a lot of benefits in terms of simplification of the architecture, scheduling and memory usage.