Step 4 -- Suspend and Resume
Step 4 is to get suspend and resume working. If a VP is suspended, then to resume it, the proto-runtime just does the same as it currently does for a VP running a C application function. This will cause the VP to resume just past the point that it invoked the proto-runtime primitive that suspended it. For VPs that were running Java code, the first thing past the suspend will be inside the JNI call. This will just return from the JNI call to the Java code. You'll write both the Java side and C side of the JNI call that invokes the existing proto-runtime suspend, and when it resumes, cause it to return from the JNI call, back into the JVM.
The key thing to learn in this step is how to suspend and resume a VP that is executing Java application code, and along with that, learn whether it makes more sense to have one JVM, and attach the pinned threads to that, or rather to have multiple JVMs, one created inside each pinned thread (multiple JVMs may cause problems with garbage collection!).
Here's how it will work.. a Java program will be executed normally, in the normal way. This Java program will use classes provided as parallelism libraries. These libraries have methods that use the JNI interface to invoke C functions. One of these methods will use JNI to invoke the proto-runtime C function that starts the proto-runtime system. Another method will use JNI to invoke the proto-runtime C function that creates a new process. It will use the approach worked out in the steps above, to hand a "seed" Java function to the "create new process" C function.
So, application programmers will write their code in Java, once, and then when it runs on a particular machine, that code will be dynamically linked to whatever proto-runtime and language plugins are on that machine.
The next thing needed is a class that acts as the gateway to the proto-runtime primitives that suspend a virtual processor and switch over to the proto-runtime. This class has static methods that use JNI to interface to the proto-runtime C functions. These will be used to create Java based wrapper libraries. So, each proto-runtime call that is used in a C based wrapper library needs an equivalent Java method, which in turn uses JNI to invoke the proto-runtime primitive. This is how the Java wrapper library will invoke the proto-runtime assembly code that suspends a virtual-processor and causes the proto-runtime request handling to start.
That will be the last thing needed -- after that, each language just needs its wrapper library translated to Java, which is separate from the proto-runtime, and minimal work. Then, the language should work, from Java code, even though the language was implemented in C, and the application code is written in Java. The application code will run inside the JVM(s) that was (were) created when the proto-runtime started up.
All the parallelism related activity will happen in C, inside the proto-runtime code and the plugin code. But the application work will happen in Java, and the JNI will be used to move between the two worlds.
My goal is for the proto-runtime code to be used as-is, without changing it. All the adaptation to Java should be provided by additional C functions written as adaptors, along with Java functions that invoke JNI.