07:52
Ok so, the threads will be managed by the kernel instead of the processes. This would likely make it easier to find threads that belong to processes and such. They would also be slightly decoupled. With the notes I have written yesterday this means that for code executing in the kernel would be strictly kernel space although locks would still be needed for synchronization and such.
07:55
It might be best to clear the kernel related code and redo it with how it is to be done.
07:58
Then processes running on the kernel could be purely managed by the kernel for the most part, how it currently is done except much cleaner.
09:15
Processes would not work if they were final, they have to be managed by the implementation.
09:23
One thing that I will need to handle, especially with a deterministic
interpreter is thread management and such. Also, the current work going into
the jvm-test could instead just be the base for all JVM based kernels (which
would require at least Java 7). Then the one which is made for Swing could be
based on that kernel itself. So rather than having multiple JVM based kernels
with the same code, there is mostly just a single one. Then all the JVM based
kernels could be backed by a potential interpreter implementation. The
deterministic interpreter requires some more work and integration into the
kernel compared to a standard interpreter. For example, process creation would
have to be checked to make sure the IDs and such are created at the expected
cycle time.
09:30
Then I will have to rehandle Main and potentially have any of its stuff be
made common. The deterministic emulator would load the JAR codes but it would
start the kernel a bit differently and such.
09:50
The base interpreter cores could be the same, just with potentially different execution models. So basically the interpreter would have a means for creating a thread along with how it should be interpreted. This way the interpreter logic such as stack shuffling and what not can remain shared and not duplicated needlessly between the pure and deterministic interpreter.
09:53
So this means that there is no pure interpreter, both are pure but they differ in execution model. One is multi-threaded while one would be step threaded.
10:28
Actually I am going to rename some classes around a bit and such. The
deterministic interpreter will become "rerecord" then I can use RR as a
prefix and such.
11:10
Having the kernel run a single cycle at a time and having a loop that runs the cycles would make it so timing can be managed by the implementation's entry point.
14:15
The -jar and -classpath should likely use actual JAR providers as such.
23:11
Wrote up a potential proprietary license which may be purchased, since it would be beneficial to the project.