18:37
The ClassPath has to be associated with processes in order to find new ones
to execute.
19:34
Putting the process details such as the class path and main class in processes and threads is a bit convoluted, especially when it comes to the interpreter. However, after the thread is initialized and the thread arguments are checked, the interpreter thread would be created then.
20:52
So for the rerecording interpreter I will need a decent object representation that would allow objects which are active in memory to be deterministic. The allocation and order counts for objects would have to be the same in every case for the most part. The garbage collector can be made deterministic. Thinking about it, the ID association (one that determines the ID of things at least for the kernel), could be made a bit more public so that the interpreter could use it. I could also move it off to a new project and have code just depend on it for example. So it would be virtually the same, except that it could be shared in more places. Then I could adjust it so that when IDs are exhausted, they can start from the start, a binary search would be performed, and if there is a collision then the list would iterate upwards. It would attempt to find an ID which is not used at all. If the backing list is not random accessed, then it can use another means. This of course would only be performed once all of the IDs have been exhausted. However, finding a free ID can just reset the next ID which would be binary searched and may be a bit faster.
21:00
So for the rerecording interpreter, perhaps a singular growable list could
be used for objects. Any new object which is allocated is placed near the end.
I should however be able to have common code between the interpreters such as
the garbage collector and such. There would also have to be a maximal bound on
the garbage collector also. For the standard interpreter the host VM garbage
system can be used with References and such in most cases. However the
rerecording interpreter will need the entire storage state to be deterministic.
So I would say that there would have to be a specified standard GC trigger
point, which when reached goes through every object stopping all kinds of
execution and sees which objects can be garbage collected. Due to circular
references, it would have to be mark and sweep and such. However, I would
basically be writing a garbage collector 3 times. One for each interpreter and
then the real garbage collector on real hardware. I must write a standard
garbage collection class and use them for all three, regardless of their slight
differences. Otherwise 3 garbage collectors would be difficult to keep
synchronized and maintained. Also, the same garbage collector would make it
more consistent across implementations. Any bugs discovered while writing the
interpreters with regards to the garbage collector can be fixed up as required.