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

   1 # 2016/06/16
   2
   3 ## 11:06
   4
   5 When it comes to `VMInterface`, there can be one that exists per process and
   6 they could communicate with each other as such.
   7
   8 ## 11:57
   9
  10 The `Class.getResourceAsStream()` operates on the JAR of the specified class.
  11 This means that I need a dummy class in classes where resources exist so
  12 that I can read the actual resources.
  13
  14 ## 12:23
  15
  16 I should have a general mascot service of sorts. All the mascots will extend
  17 the base class however the original high resolution images would be placed in
  18 an original class. Then this way I can have a somewhat shared means of finding
  19 images to use. The base resource lookup class can even handle decoding the
  20 hexadecimal data and providing a binary stream.
  21
  22 ## 13:33
  23
  24 Mascot images could actually be provided with the `ServiceLoader` so that a
  25 format as required can be specified and such. Then the instances of the service
  26 will be in the JAR so that `getResourceAsStream` would work there.
  27
  28 ## 14:23
  29
  30 Never figured that I would have refactored the mascot projects other than
  31 resorting.
  32
  33 ## 15:10
  34
  35 I kind of just want to work on MEEP for a bit.
  36
  37 ## 15:17
  38
  39 Then I can have some kind of interaction and I can take a break with
  40 Squirrel Quarrel when desired.
  41
  42 ## 15:27
  43
  44 Actually going into this, the application management services does exactly
  45 what the launcher would need to do for the most part. So this means that my
  46 previous launcher idea was a bit flawed anyway. So for the most part with these
  47 interfaces, I will have to integrate them as such.
  48
  49 ## 15:45
  50
  51 Actually one thing that I can do is have a host virtual environment. Unlike the
  52 kernel, this would run the bytecode on the host system. It would not be
  53 interpreted and use the pre-existing JVM. This would be a system that could be
  54 used for testing or having a basic feel of the entire system as a whole.
  55 Due to the requirement of there needing separated execution states, input JARs
  56 would be read and their classes modified so that they are in their own unique
  57 per-process (classpath) package.
  58
  59 ## 16:00
  60
  61 This could actually work, it would be a kind of Para-Virtual Java Virtual
  62 Machine which would run on Java SE systems. It could theoretically run on Java
  63 5 however the code uses try-with-resources so that would not work much. The
  64 PVM could implement SquirrelJME and I can work on it through that. Then once
  65 the class library is complete I can perform native ports. The ports would need
  66 minimal code to be implemented, so in theory I should never run into a TODO.
  67
  68 ## 16:09
  69
  70 To think of it, with some adjustments on how classes are loaded the JVM has the
  71 Pompek and Goldberg requirements for virtualization. The only thing that needs
  72 adjusting is the classes which are used. When a class is loaded, the loader
  73 will essentially rewrite all classes in the JAR so that instead are prefixed
  74 with say for example `__squirreljme.pvm.processid.` where `processid` is a
  75 specifier for a given process. Each process has its own `ClassLoader` which
  76 performs the translation as required. Since each class would be duplicated in
  77 a process this would mean that they have their own set of static globals and
  78 otherwise. Since all classes would be erased and replaced with the process
  79 specific classes they cannot see this fact at all.
  80
  81 ## 16:15
  82
  83 One thing I have to consider is that application management such as which
  84 JARs are available and such has to be common so that I can simply use the
  85 same code when it comes time for a native port.
  86
  87 ## 16:17
  88
  89 This means that `javame-meep-swm` instead will need to wrap some kind of common
  90 interface which manages applications. These would definitely have to use the
  91 unsafe interfaces and classes.
  92
  93 ## 16:57
  94
  95 Ok, so when it comes to applications and such, there will be a `VMInterface`
  96 which provides a list of all JAR files which are available. This would be using
  97 a system specific means of providing built-in and other such JARs. Another
  98 thing that I need to do is make it so the `VMInterface` is split and just does
  99 not have a few hundred methods of varying function.
 100
 101 ## 17:00
 102
 103 It will be called `VM` instead.
 104
 105 ## 17:24
 106
 107 I dislike large thunderstorms.
 108
 109 ## 17:47
 110
 111 The power failed and it seems the battery attached to my UPS has not held a
 112 significant charge (it is 6 years old however). The battery generally should
 113 last about 10 years however, so hopefully it is not a lost cause. However with
 114 battery powered laptops, I am still able to program. Just program in silence
 115 for the most part.
 116
 117 ## 18:19
 118
 119 Alternatively I can design the system interfaces first and get away with what
 120 ever I want with the PVM. Then when it comes to native ports, I can determine
 121 the best way everything fits together, such as having the kernel previously.
 122 This way I can design it comfortably when it comes to the PVM and instead no
 123 worry about having the native interfaces intermingled. It would duplicate the
 124 native port however, although by that time it would give me enough information
 125 to reliably create a good interface for natively compiled systems.
 126
 127 ## 18:26
 128
 129 I saw something in the SWM interfaces about daemon applications. That could
 130 be useful in a way.
 131
 132 ## 18:34
 133
 134 The loading of all the package information takes a bit on my system.
 135
 136 ## 18:40
 137
 138 I can likely make the ZIP code faster by removing the structure bits. The
 139 structure is a nice and a bit faster way to read ZIP data. Also the singular
 140 read buffer could be replaced by a cached group of temporary buffers so that
 141 reading is a bit more efficient than usual. If multiple threads are reading
 142 a single ZIP then they must fight for the buffered data.
 143
 144 ## 18:43
 145
 146 `FileChannel` supports reading from any position, while `SeekableByteChannel`
 147 will have to be locked to prevent multiple threads from changing the position
 148 during a read.
 149
 150 ## 18:47
 151
 152 If I do remove all the structure information and instead just use straight
 153 arrays and such, then reading should be a bit faster. What I could do in
 154 general is have it where pre-wrapped `ByteBuffer`s are available to be used
 155 and read depending on the size that they are. However previously I did not very
 156 large arrays and chunks to be allocated because they could be wasted. However
 157 using `Reference` and try-with-resources can give me a buffer of what I need.
 158 So it would essentially be a wrapped `ByteBuffer` in a way. Then hopefully ZIPs
 159 will be read a bit faster. If I also perform bulk reads instead of individual
 160 reads then there would be less locking being performed.
 161
 162 ## 18:50
 163
 164 So the time it takes to run everything before:
 165
 166  * 7.6s
 167  * 7.5s
 168  * 7.7s
 169  * 7.6s
 170  * 7.6s
 171
 172 So I want to get this down to perhaps 2s to read all of the package lists. If
 173 it takes 7 seconds on this (decade old) system then it might take 30 seconds
 174 on an even weaker system.
 175
 176 ## 18:53
 177
 178 I can also rename the classes, so instead of `StandardZIPFile`, it is just
 179 `ZipFile` instead. I can also move off the inner classes and place them
 180 outside of the interface also.
 181