Step 3
The third step is to make a Java interface start up the proto-runtime system, and the interface that starts a process in it.
I believe there are two basic approaches that can be taken to starting up the proto-runtime system. One is to have a single JVM that all the threads share, versus having as separate JVM for each core.
Either way, during startup, the proto-runtime creates an OS thread for each core and pins that thread to the core. This happens in the existing C code. The OS thread is born running proto-runtime code. So, the task here is to write a birth function that either attaches the OS thread to the shared JVM, or it makes a new JVM for that pinned thread (will have to experiment to find out which is better).
Now, if we go with a separate JVM for each core, then the birth function will make the JNI call that creates a JVM. That way the JVM is running in that pinned thread. The JVM will have to be born running a special Java program. This special Java program does one thing: it uses JNI to call proto-runtime code. The called C function uses the proto-runtime to suspend the thread, which consequently also suspends the JVM and switches the core over to the proto-runtime code.
The proto-runtime can create new proto-runtime virtual processors (VP), and cause the JVM to start executing Java code in those new VPs.
The end effect will be that the machine has an OS thread pinned to each core, and that pinned OS thread has a suspended JVM, and both are under proto-runtime control. All of these threads are sitting idle, part of the proto-runtime system. The proto-runtime system will put them to work once a language creates some work.
This link talks about creating a JVM inside a C thread: http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html
An alternative may be to have all the proto-runtime threads be attached to the same JVM, via the JNI AttachCurrentThread() call.. will need to gain more understanding and do experiments in order to see which makes more sense.. the thing that concerns me is the garbage collection..
I actually think this second method is the best one to try first, due to the garbage collection and the myriad of threads that each JVM creates.. However, on multi-socket systems it may give a significant performance advantage to have a separate JVM on each socket, to avoid sharing JVM internal state between sockets..
Once the proto-runtime has the suspended JVM(s), then it can cause a JVM to execute the "birth" function in a new virtual processor created by the proto-runtime. How to do this was worked out in the experiments in step 2, above. So, the last part of this step is get the birth function for the new process running in the seed VP of that process.