Right now, ScriptExecutor operates on several collections that can interact with threads other then the VM thread and, therefore, require heavy synchronization while accessing this collections. This issue is not critical, but may impact performance, as well as make the code less structured and more chaotic. Therefore, it's important to develop as lightweight synchronization strategy as possible (ideally - one synchronization per VM event loop cycle) and implement it.
once in every loop cycle when there seems to be no more work to do: waiting for some new work without CPU consumption
adding and retrieving messages to and from the message queue. Most often, and for most message kinds this is not really needed. We need to investigate what message types may be added to the queue from other threads than the main thread. It could be useful to create sub-queues per message type so that most operations will not need synchronization.
Right now, ScriptExecutor operates on several collections that can interact with threads other then the VM thread and, therefore, require heavy synchronization while accessing this collections. This issue is not critical, but may impact performance, as well as make the code less structured and more chaotic. Therefore, it's important to develop as lightweight synchronization strategy as possible (ideally - one synchronization per VM event loop cycle) and implement it.