assets/developer-notes/stephanie-gawroriski/2014/11/18.mkd

   1 # 2014/11/18
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 00:09
  10
  11 A rather nice IDE, however it is really sluggish when it comes to typing as
  12 the words I type appear about as second later. Oh well. Maybe when my OS gets
  13 far enough I can use NetBeans on that instead. In general though for my code,
  14 my TypeInfo class is far too complex and does everything for all types of
  15 input. Perhaps the best thing to do would be to subclass TypeInfo and have
  16 inner classes be TypeInfos so to speak. This way they have specific
  17 information and do not share some global state (where some of them are null).
  18 The only main problem are poly types that mean multiple things, such as class
  19 bounds which could also be an exact type bound. Perhaps interfaces could be
  20 leveraged for this.
  21
  22 ## 00:20
  23
  24 Actually for TypeInfo bounds, the exact stuff can be exactly what something is
  25 so that there is no exact bound. So I would at most need an interface that
  26 indicates the specific sub type can be a part of a bound list. So right now
  27 TypeInfo is 1680 lines long (and I do not have type parameters implemented).
  28 It contains a bunch of convoluted code for various cases and decoder loops, so
  29 I need to simplify that greatly. Another thing that will need to be done is
  30 switching to a ProgramBuilder for generation of SSA codes, that way it can be
  31 done efficiently.
  32
  33 ## 12:02
  34
  35 So now work begins on moving the TypeInfo stuff over to a new and improved
  36 system.
  37
  38 ## 12:21
  39
  40 How about rather than decoding it when it is passed, I do a lazy encode and
  41 just partition it based on the characters inside of it. Since descriptors are
  42 full of unqualified names and those special unqualified characters are used
  43 for the generic bits and such. But that would not work because method
  44 indicators are legal in class names.
  45
  46 ## 20:38
  47
  48 The main unknown thing byte code wise is volatiles and getfield/putfield. Are
  49 these volatiles handled at the byte code level or at the language level?
  50 Because if they were at the bytecode level then the local variables or stack
  51 would have to be mapped to the volatile variable.
  52
  53 ## 21:11
  54
  55 Appears that it is virtual machine level as volatile and non-volatile byte
  56 code is exactly the same in my tests.
  57
  58 ## 21:19
  59
  60 Due to the volatiles and such, I will need to depend on other clases being
  61 available at runtime and using their information, so I will need a system to
  62 keep track and load them as needed. However, loading everything could be very
  63 slow because the entire library will end up being loaded, so the only thing
  64 that will request loading of other classes is the class compiler. This has to
  65 be written so that it can work for the kernel also. So there would need to be
  66 separate commit levels and such. And since classes rely on TypeInfo, they must
  67 be decoded. So for the fastest speed possible there must be a lazy decode of
  68 type information. A type could be loaded by a class and stuff might have
  69 already been cached when another class was processed. And the bus stuff has to
  70 be done so that it does not require a load of normal class files if the stuff
  71 is already compiled, and if it has not changed.
  72
  73 ## 22:03
  74
  75 This class bus system will be the bulk of the kernel classpath searches and
  76 such, the kernel will have the boot classpath while userspace processes (that
  77 share the same classpath) will have sub-busses, if the parent level ClassBus
  78 lacks a class, it is then searched for in the sub-bus. Then the ClassBus
  79 system can replace most of the link stuff because it would handle the
  80 searching of classes when needed, although it will still need something that
  81 looks at a JAR or directory for class files. A parent class path will have to
  82 protect packages from getting new stuff added (so client classpaths cannot
  83 mess around with java.lang stuff and such), this sealing would be always on.
  84
  85 ## 23:39
  86
  87 I think right now it is mostly guess work on how everything will operate,
  88 since I lack a kernel. I need to really guess how the kernel will operate
  89 before I even write it, which can be difficult. One incorrect move and things
  90 get invalidated. Perhaps I will have to implement my previously dismissed idea
  91 of writing the kernel in Java and having an actual system running on an
  92 existing JVM. Then once I get the compilation system setup and all of that I
  93 can then port it over to real hardware and such. However such a kernel would
  94 have to be setup so that it is efficient and does not run like garbage or
  95 break on real hardware. So the main important thing would be handling Java
  96 being like a CPU without an MMU. Then there would need to be recompilation to
  97 run code on the actual machine, but this can be done by recompiler that take
  98 byte code and turn it into byte code. Although the byte code to run on the JVM
  99 will be very magical. Thread.suspend() and Thread.resume() give me multi-
 100 threaded control although those methods are deprecated because they are
 101 deadlock-prone, so if I were to avoid using those I would have all the threads
 102 running at once or make a cooperative type system in the code.
 103
 104 ## 23:03
 105
 106 I believe completely avoiding the use of assembly is suicidal as I need some
 107 kind of initialization system, however the assembly could just be used to jump
 108 into a giant precompiled Java blob of the bootloader after initializing some
 109 native callbacks to do somethings which are very special.
 110
 111 ## 23:16
 112
 113 At least permitting assembly relaxes the need to make super special compilers
 114 that do magical stuff (like I planned on doing).
 115
 116 ## 25:35
 117
 118 I believe my main problem is being too complex too soon, although doing it the
 119 semi-complex work will save time and implementation future work without any
 120 headaches hopefully. If I did a straight Java byte code to machine code then I
 121 would have to write byte code recompilers over and over again so what I am
 122 currently doing is good. MIPS will probably end up being the first supported
 123 thing because it is so simple to code for and a nice instruction set, there is
 124 also QEMU's support of it also.
 125