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

   1 # 2016/06/24
   2
   3 ## 11:39
   4
   5 Based on the URI specification, the scheme specific part is always the path.
   6
   7 ## 11:48
   8
   9 Actually a class path system based on URIs could be complex although rather
  10 future proofed. `java.net.URI` has really non-conforming URI layouts and some
  11 of the constructors are very simple and just paste strings together rather
  12 than encoding them as they should.
  13
  14 ## 11:57
  15
  16 Actually the JVM could be backed using the standard MEEP interfaces. Instead of
  17 having `class-path`, I just instead have an implementation of the
  18 `SuiteManager` and `TaskManager`. The base would act as a kind of kernel of
  19 sorts.
  20
  21 ## 12:00
  22
  23 So there would be basically two levels. A JVM would run as the kernel which
  24 then manages sub-JVMs running at lower ends.
  25
  26 ## 12:15
  27
  28 Perhaps the `JVM` can be `final`. Then it can either be constructor or an
  29 implementation specific factory be used. At least with an implementation
  30 specific factory there can be fallbacks in the event new features are added
  31 to the JVM. If something is missing then there would be a fallback.
  32
  33 ## 12:32
  34
  35 So the first thing to do for the ability factory is provide an interface that
  36 would be used with the Suite manager to find the launcher JAR. Then once the
  37 JAR is located a task should be created and then switched to.
  38
  39 ## 12:38
  40
  41 The JVM's suite manager should have only a single implementation managed by
  42 the JVM itself. However, due to some of the varying needs that might not exist
  43 (such as a filesystem), suites should still be installable by passing the raw
  44 JAR bytes for example (after a download or other unpack).
  45
  46 ## 12:46
  47
  48 I will need to implement the classes used in the suite manager since they do
  49 not exist and I have no templates to base from.
  50
  51 ## 14:31
  52
  53 I wonder why `SuiteInstaller` and stuff such as `Suite` are classes instead
  54 of interfaces. I suppose the intention that despite there being many managers
  55 that there will just be a set few when it comes to suites? Regardless, the
  56 suite managers and such will instead be an artifact that is used in the
  57 user space process and not the kernel. Otherwise when it comes to suite
  58 management the kernel can get confused if it is running a virtual enviroment
  59 on SquirrelJME or another Java ME implementation.
  60
  61 ## 14:48
  62
  63 Especially since `Task` is `final` that means it cannot be used at all. So
  64 SWM is completely client side. However after manually typing out the classes
  65 I have a feel of how it would work.
  66
  67 ## 14:58
  68
  69 Unless the `Suite` and `Task` have package private or private constructors that
  70 do not exist in the documentation. JavaDoc really should have included
  71 information if a class can even be constructed at all. I am going to guess that
  72 the constructors are private or package private. The classes that exist are
  73 just stubs which even lack constructors.
  74
  75 ## 15:29
  76
  77 And with that the entire MEEP SWM has been implemented. That took about 3 hours
  78 or so to complete.
  79
  80 ## 15:29
  81
  82 So what I need to do when it comes to the `JVM` since SWM is application side
  83 (and not JVM side) is just provide access to the available suites via the
  84 `unsafe` classes. So the suite code and such will just call into the system
  85 code and such. However the `JVM` itself can still use some of the MEEP flags
  86 and states such as the enumerations. So there will essentially just be a JVM
  87 side of the MEEP code that `unsafe` bridges to.
  88
  89 ## 15:37
  90
  91 Ok so since including all of the verification details and class transformation
  92 would be difficult in the `JVM`, perhaps the launcher can perform all the
  93 details. When an application requests to download a JAR from the internet it
  94 can instead forward the request through to the launcher. So basically the
  95 installation system of a JAR is purely handled by the launcher. The JVM would
  96 have a full permissions mode which is used by the launcher. When it comes to
  97 the JVM's set of suites, there will just be a basic install output stream of
  98 sorts. This would assume that the launcher verified all the details and such.
  99 So the JVM's default suite (to replace the class path stuff) will just
 100 contain a simple interface means of accessing built-in suites that are
 101 pre-installed. In the event of native code, these JAR suites would be
 102 completely built into the executable (and not be in other JARs). However in the
 103 case of the JVM based one, it will just treat all JARs in the current
 104 directory as preinstalled. Then with it done this way, this would mean that
 105 native binaries just come alone with precompiled code and suite setups. The
 106 access to preinstalled suites will just basically be `getResourceAsStream`
 107 and likely another interface such as an executable class context.
 108
 109 ## 20:26
 110
 111 One thing I can do is potential native integration of sorts. Have the
 112 SquirrelJME executable. For each installed program a new binary appears. This
 113 binary is just a wrapper which then calls SquirrelJME with the program that
 114 it represents. The program would just launch and provide an icon for the
 115 most part. So for example on Palm OS native applications can be created and
 116 placed on the list of applications to quickly switch to JARs which are
 117 available. There could still be a single SquirrelJME process running with the
 118 VM however.
 119
 120 ## 20:40
 121
 122 Well actually the JVM has the native compiler and not the launcher, however
 123 when it comes to native execution of code the JVM could recompile any classes
 124 that need to be recompiled if they have not be cached or similar.
 125
 126 ## 20:45
 127
 128 Due to my goal of supporting very limited systems, perhaps my handling of the
 129 classes is completely wrong. Right now when it comes to compilation I will
 130 basically load everything about the class into memory. Then that gets
 131 natively compiled. If I can make it so a Java class file can be put into an
 132 input stream which is passed to compiler. It performs some basic verifications
 133 that it can perform at the given stage along with basic stack map details and
 134 such. It will basically just fly through the code attribute as is and perform
 135 compilation in a single pass, perhaps without even loading the exception table
 136 and stack map table attribute. Then the code can pass through the micro
 137 operations execution-like system for each operation. Then that would be
 138 output to the JIT which produces native code for a method. Once all of the
 139 native code has been compiled it will then package it in an executable blob
 140 that will be loaded into memory or become part of global blob in an executable.
 141 If the blob route is taken then executables can just be made out of a bunch
 142 of executable blobs with some initialization code (so the `JVM` can load).
 143 Having a JIT on systems with as small as 64KiB could potentially be done using
 144 this method. It would also be very fast. The ZIP code requires a sliding
 145 window however, so as long as the classes remain small they should work on
 146 a multitude of systems. So classes need to have not many methods and be within
 147 a given size. I would suppose in the build system I can warn if a class
 148 exceeds a given size (so I can trim it). I would suppose that the lowest of
 149 lower limits I can go for is 4KiB. If a class exceeds that size then it is
 150 way too large. The larger a class, the more difficult it is to handle as the
 151 more memory it consumes.
 152
 153 ## 20:59
 154
 155 4KiB might be a little too low, especially if there is debug information in
 156 the JARs. However, debugging information is rather useful to have at least
 157 for now. So I suppose the current limit I can impose is 12KiB. When writing the
 158 JARs for a distribution I can strip the debugging information anyway since
 159 SquirrelJME would likely not be capable of line based debugging.
 160
 161 ## 21:08
 162
 163 So I need the JIT to be as small and as fast as possible while using the least
 164 amount of memory. This would then equal faster than interpretation on limited
 165 systems. Due to the lack of reflection and invokedynamic I do need to perform
 166 some checks. I would suppose that the code generated in a class should be
 167 together as one. At the end of a class chunk there can be symbol information
 168 which contains information on any classes which are referenced along with
 169 methods. Then with this, blobs can be independent. The only major concern are
 170 that symbol references can be quite long. So I suppose a UTF-8 form
 171 is used so that characters take up a byte instead of a char in the file. I
 172 can have special String handling for UTF-8 strings with non ASCII characters in
 173 it. However in the general case this will never be the situation because when
 174 it comes to class names and such, there will generally never be characters
 175 beyond the basic ASCII range.
 176
 177 ## 21:15
 178
 179 Another consideration is that there can be symbolic special names which use
 180 a preset dictionary to refer to classes. There can even be prefixed forms of
 181 these too. So if I limit strings to be 32768 bytes then that means I can use
 182 the upper bit for a string prefix. The `String` class can handle these special
 183 prefixed data. I would also have to memory map the class constant data area
 184 also by using `byte[]` which write to actual addresses. Using handles as I
 185 plan to do means I need not worry about it. When it comes to a prefix I can
 186 support 127 of them, then 255 bytes can be used for remaining UTF-8 data.
 187