Elaborate a base strategy to implement a parallel scheduler.

[viferga]

TODO: This is a draft, it must be improved.

The main motivation of Hz/Isolate is to generate a standard multi-core parallel library for HertzScript. HertzScript implements green threads, in other words, in the nowadays JS implementation (09/15/19) it can compile existing code into a re-entrant version of it. Thanks to this capability, Hz is able to execute code concurrently in run-times that does not support it. Hz is a specification, but in order to illustrate this example, Hz current implementation (based on JavaScript) is a compiler (transpiler) based on Babel. Thanks to this Hz is able to transform all calls into a re-entrant version of it. This means, by means of a transpiler plugin Hz is able to hook into all your function calls, this mean, each step (function call) of your code is tracked (detoured) into Hz. So adding a compilation step to your code, with Hz we are able to stop the execution and resume it whenever we need.

This property is very important. It allows us to implement multiple hooks. A hook is an additional functionality applied to a code that already exists. For example, a debugger like GCC (dynamic) or Counter Strike AMX-MOD (static). After using Hz compiler, we can generate a JavaScript code that it is able to be executed, stopped, and resumed arbitrarily.

Thanks to this mechanism, we can begin to implement different behaviors. For example, Hz is focused on concurrent execution (green threads) but we can also hook functions in order to generate better stack traces, run-time code analysis or meta-programming techniques.

At the current state, Hz effectively generates re-entrant code that can be used as green threads. For example, what the class Thread of CRuby (MRI) implements, but the implementation has some differences. CRuby (MRI) implementation is very similar to CPython, in many aspects but specially at Threading level. Ruby and Python use a common global mutex that prevents race conditions from execution by blocking the whole Interpreter (as a difference to JVM that is designed to be atomic). In the case of V8 we used to have a similar limitation, latest improvements lead us to a basic way of parallelism (thanks to Multi-Isolate). V8 has an internal structure called Isolate, which in a few words, represents the context of the execution of your JS code. Since version (TODO), V8 implemented support for multi-isolate environments. This gives to us a better solution in terms of parallelism compared to Ruby green-threads, but at the same time it gives us a very low level API, difficult to use from the point of view of the user.

HzIsolate tries to mix both worlds, Hz green threads specification, with V8 Multi-Isolate implementation, allowing multiple tasks to be executed by different threads arbitrarily. This is a similar model that GoLang implements. It is a N:M stack-less/re-entrant design which allows to execute concurrent code in parallel, depending on the real OS threads.

Apart from current limitations, the final target of HzIsoleate is to be able to analyze the current code statically, and also, introduce a run-time, in order to execute existing code in a parallel way if it is possible, or provide an API of primitives to existing run-times that does not support parallelism as a standard library.

Talking about JavaScript, common use cases of Hz (without Isolate) are the following:

• Real time tracking of a resource (telemetry, advanced debugging, control, meta-programming).
• Concurrent execution of JavaScript code within a single thread execution:
  • Calculating two Matrix concurrently of a WebGL application (executing JavaScript operations concurrently).
  • Web Game Engines (mixing I/O with concurrent programming can simplify the design of Web Games).
  • Responsive (non-blocking) UX (independently of the user code or underlying technology (even with the Event Loop blocked, the application can continue)).

With the Isolate module (plugin), we are focused on improve default capabilities of Hz by providing parallel execution over concurrency, thus allowing a real N:M model and exploding the performance of the cores.

With this model we can create similar applications as GoLang, but not only mixing the asynchronous I/O but also, allow computed based applications to be executed in parallel. NodeJS (or browsers) use a thread pool as a deferred work. The benefit of this technique is that it allows to safely execute operations in parallel, but it is not enough. Our JavaScript code will be executed in a single thread. We want to combine both operations, execute JavaScript code in parallel and explode the I/O world. Our main motivation is to allow existing code to be executed efficiently in environments FaaS (Function as a Service) like, or high intensive computation applications.

An alternative to this application is to make V8 completely atomic, like JVM does. But this is not an option right now due to the current state of the art. So we provide an intermediate solution for JavaScript (and other languages) for achieving these capabilities.

Reference about the implementation in V8: https://stackoverflow.com/a/44359082

[Floofies]

b1600be