assets/developer-notes/stephanie-gawroriski/2016/06/03.mkd

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