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

   1 # 2016/06/14
   2
   3 ## 08:34
   4
   5 I would suppose that processes should have their own unique structure manager
   6 which is derived from the top level structure manager provided by the kernel or
   7 interpreter. This way it is easier to tell which objects belong to a given
   8 process along with having each process have their own set of objects which can
   9 completley cleared when a process exits. The kernel itself can just use the
  10 host object manager for the most part.
  11
  12 ## 08:39
  13
  14 However when it comes to objects and the kernel itself, there can be a kind of
  15 circularity so to speak. The field positions within objects are needed by the
  16 dynamic compiler and the static compiler to know where fields and methods
  17 are in relation to an object or class.
  18
  19 ## 08:47
  20
  21 However, where I am going right now has to be adjusted. Currently all the
  22 classes for a process would be reloaded along with their information. I need to
  23 have it where a class could be derived from the kernel itself. So I suppose
  24 what I need is a `RuntimeClassPath` which is very similar to `ClassPath`
  25 except that classes provided by the kernel are shared among all processes. So
  26 when a new class is requested it is not duplicated. Another thing to consider
  27 are class units. Static class data does not really change much at all, just in
  28 the dynamic linking information. I will need another similar thing to the
  29 `ClassPath` except one that manages singular class units. So in the event that
  30 a `ClassUnit` is shared amongst multiple processes, the information such as its
  31 field alignments will already be known. The one thing that is not known however
  32 would be the class base offset (for super classes).
  33
  34 ## 08:54
  35
  36 So to think of it, perhaps when it comes to the kernel, the kernel should not
  37 have a `RuntimeObjectManager` at all. The kernel can be completely oblivious
  38 for the most part about how objects are laid out in memory. It just needs a
  39 way to call the garbage requester when requested.
  40
  41 ## 08:58
  42
  43 However, when it comes to the current layout the interpreter and the kernel
  44 which uses the interpreter are completely separated. However the object
  45 spaces are pretty much the same. So perhaps instead the `RuntimeObjectManager`
  46 is given `ClassPath`. I remembers the class unit which contained a class. There
  47 could then be a hierarchical layout to it. The kernel gets the root `ROM` and
  48 then the processes get their own `ROM` as I stated before. However, to reduce
  49 the duplication of `ClassUnit`s in `ClassPath` they need to be shared.
  50 Otherwise there can be pointless duplication of `ClassUnit`s.
  51
  52 ## 09:05
  53
  54 `ClassPath`s however can be combined from `ClassUnit`s in a way where two
  55 class paths could have a similarly named `ClassUnit` from a different provider.
  56 The only way to tell them apart is if they are a different object (they are not
  57 `==` to each other). So I suppose in this case I have a `ClassPathProvider`
  58 which instead of using `ClassPath` to create sets of classes, the provider is
  59 given the units and it returns the `ClassPath` instead. Then individual
  60 `ClassUnit`s and the classes contained in them can have implementation
  61 dependent objects associated with them. So then this way, there should never
  62 be a new of a `ClassPath` outside of `ClassPathProvider`. I could even make
  63 `ClassPath` private so to speak and have it only be generated by the provider.
  64 Then with a generic flag this can be used for object association. The
  65 `ClassPath` would have wrapped class unit references. When a class is requested
  66 each unit is checked for given class information. If object layout information
  67 is requested (this would be the _unknown_ special object) then the `ClassPath`
  68 can determine which wrapped `ClassUnit` contains the given class and then
  69 use the information in the given `ClassUnit`. After verification, the
  70 `ClassPathProvider` can call a callback method which can initialize the
  71 internal object reference. This way to the outside it cannot be set and appears
  72 to be an immutable reference. The internal object initializer would already
  73 have the memory accessor associated (for alignment and such) and it would then
  74 calculate the alignment where all the fields should be. Then I would suppose
  75 in the `ClassPath` there is another object association which knows about the
  76 global `CIClass` specific information along with `ClassPath` specific
  77 information. The information that is stored in the `ClassPath` instance could
  78 be instead the base class alignment from the object base and the size of the
  79 class. This way the internal field alignments only need to be calculated once
  80 despite them being shared across multiple `ClassPath`s.
  81
  82 ## 09:15
  83
  84 The compiler could also use the alignment information to determine where fields
  85 exist within the kernel and such. The only issue is with the statically
  86 compiled `Kernel` itself. I would very much like to have its `CIClass`es be
  87 shared among the internal threads. So there would need to be some kind of
  88 initialization that can be generated by the compiler which gives the location
  89 and sizes of objects. So that for the most part, the CLDC classes are already
  90 precompiled into the kernel.
  91
  92 ## 09:21
  93
  94 However for that, the kernel would need precompiled `CIClass` objects. So
  95 what I can actually do is have kernel internal offset information. The
  96 compiler for every class which is internally represented would create a
  97 virtual `CIClass`. The class would implement `CIClass` and contain all of the
  98 internal kernel details. The compiler would just not create virtual classes
  99 or all of the virtual classes (because otherwise it would create an infinite
 100 amount of classes). Those virtual classes would exist but they could never be
 101 `forName()`ed because they would not be in the kernel's run-time system. The
 102 virtual `CIClass`es representing the classes which were statically compiled
 103 will be combined into a single `ClassUnit` which returns them depending on the
 104 requested class. Then when it comes to the alignment information, the same
 105 thing will be done. These virtual classes would contain said information.
 106
 107 ## 09:26
 108
 109 So basically, having the interpreter (even if it rerecords) appears to be the
 110 incorrect route to take. The interpreter and its object space is completely
 111 incompatible with native object spaces and how it actually exists. So I suppose
 112 what I need instead is to write a simulator and then target that simulator with
 113 the native compiler. Then when it comes to interpretation, completely ignore
 114 the interpreter and drop it completely. Details of classes and such are already
 115 fully handled to my knowledge. However, since I am on Linux PowerPC, I should
 116 write a simulator which can run PowerPC Linux programs (such as say `nethack`)
 117 first because there are simple binaries that can be tested. Once simple
 118 programs are supported I can then go onto the native compiler, compile some
 119 classes, then run the code in the simulator.
 120
 121 ## 09:51
 122
 123 Instead of a rerecording interpreter, the simulator can support that instead.
 124 One thing that is needed would be a binary format support library for ELF, a
 125 PowerPC execution engine, and a Linux system handler (handles system calls and
 126 file system details).
 127
 128 ## 10:04
 129
 130 I need to handle a recursive optional dependency and make sure that is not
 131 included.
 132
 133 ## 10:58
 134
 135 I would suppose that the root in the simulator could also be a ZIP file which
 136 can be used to access files. This way on systems where it is not possible to
 137 represent a given host filesystem, it can at least be placed in a ZIP. However
 138 a file would have to completely be read in due to compression and cannot
 139 quickly be memory mapped. So a very large file attempting to be memory mapped
 140 will cause the file to be recreated on the virtual system or using some other
 141 means.
 142
 143 ## 13:06
 144
 145 Some operating systems rely on block devices to provide filesystems, while
 146 others can use virtual file systems quite easily. Having a command line based
 147 configuration for a simulation sequence can get quite complex. So the question
 148 is, I need an easy to use configuration system that can provide the program
 149 and the required arguments to the simulator. This way when it comes to testing
 150 natively compiled SquirrelJME on the simulator a number of configurations can
 151 be used instead of having the test system specify the required command line
 152 arguments. This would in a way greatly simplify setting up the simulator and
 153 would allow for it to be extended by the configuration.
 154
 155 ## 13:13
 156
 157 One thing which I should support is multiple processes that run under the
 158 simulator. It may be required by some programs that a new process is created
 159 or a fork is performed of an existing process. So I should support such a
 160 thing along with multi-threading.
 161
 162 ## 13:30
 163
 164 Actually, the simulator is more like an emulator for the most part. However the
 165 environment that would be running in it would not be a drop-in replacement
 166 because Java ME for example lacks stdin which some systems have and may rely
 167 on.
 168
 169 ## 13:36
 170
 171 Also, the system would be able to operate with no ROMs and generally will
 172 perform high level emulation of well behaved systems.
 173
 174 ## 13:46
 175
 176 One thing I can also have is simulator groups. For example, I might want to
 177 test communication between a DOS system and a Linux system over a virtual
 178 serial port possibly, so as such the two systems should be able to
 179 communicate to each other in the simulated environment. There could also be
 180 a combined networking system connected to each system.
 181