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

   1 # 2016/03/24
   2
   3 ## 00:35
   4
   5 Instead of having a single class per instruction, I can always split it up
   6 into groups. Then this way I do not need to worry much about having tons of
   7 classes. However some operations may be more difficult to find. However, I
   8 would say that having less classes with more meat would be the better
   9 alternative than very slim classes. It would require switch statements in the
  10 classes though. Those 256 classes would count twords the total class limit I
  11 will be imposing on the VM. Right now I have 250 classes total in all of my
  12 sources (well, 250 .java files). Plus some nearby operations have similar
  13 function and such. It would also mean that the cache reference array is a bit
  14 smaller too (which can be a good thing). There would also be less potentially
  15 stale reference objects in memory also. So if I set the shift to say 4, then
  16 I only need 32 elements.
  17
  18 ## 10:02
  19
  20 I do not actually need unique IDs for basic optimizations. I can just have an
  21 active stack slot so to speak which points to preallocated registers and such.
  22 So I will need a list of native registers and such.
  23
  24 ## 10:26
  25
  26 I will need a kind of a virtual working system which is lazy. Basically I
  27 work with virtual registers which may be in locals or on the stack, then I
  28 determine operations which are to be performed on them in a linear sequence.
  29 When the registers go away (they are overwritten) then they are stored before
  30 they are destroyed. Probably do not need to store them when memory barriers
  31 are hit because these are just registers. So instead of generating code that
  32 just copies from one place to another, adds some values, then stores that
  33 result into a temporary. It is basically just:
  34
  35  * Read int value from local #4, push to stack
  36  * Push 2 to the stack
  37  * Add the top two stack elements (virtual stack, and virtual local #4)
  38  * The result is stored on the virtual stack position.
  39
  40 The result will exist purely virtually and will not be stored by default in
  41 most situations. However invoking a method will require that the value is
  42 stored somewhere if it is not consumed by the method call. Well, actually I
  43 might not even need to use the value at all. One could write byte code which
  44 adds a bunch of values together and then just `pop`s the result meaning it was
  45 pointless. So even during method calls I do not store it. The only time I have
  46 to actually calculate the value is if it gets stored into a field (instance or
  47 static), called into a method, thrown, allocate a new object, allocate a new
  48 array (possibly even multidimensional), entering/exiting monitor. If some
  49 operator chains are simple say byte code adds 2 + 2 + v, I can just turn that
  50 into 4 + v. So if a bunch of math is performed on operations, I only really
  51 have to perform the work when it becomes visible to the outside of the method.
  52 This can be used for optimization and removing the bulk of Java's stack like
  53 nature and could result in smaller code being generated. It would require
  54 however that the position of exception handlers and the stack map table be
  55 known for optimal work. Because if values are calculated and it just turns out
  56 they are never worked with because some exception is tossed... Well actually
  57 if they are in a local they will stick around to excpetion handlers. So for
  58 each possible local variable state exists, there has to be one for each handler
  59 of exceptions. So it is possible that operator chains can be ambigious in
  60 this event. So I will have to specially handle exception handlers and operator
  61 chains. So I propose that if a local is written to when there is an actual
  62 exception handler that is present, that the operator chain is calculated. If
  63 there is no exception handler and then suddenly there becomes one, then all
  64 the operator chains associated with local values are calculated and code is
  65 generated for them.
  66
  67 Essentially this results in operator chains for register values, which can be
  68 used to determine how values are used and such.
  69
  70 I made a base class JVMNativeRegisters with stuff in JVMProgramOutput, so I
  71 could likely simplify things a bit. I could have special program outputters
  72 which can virtualize int/long/float/double operations if not supported. This
  73 would be needed for 8-bit and 16-bit systems where 32-bit integer math is not
  74 supported at all.
  75
  76 ## 10:40
  77
  78 So implementing `JVMNativeRegisters` and the related stuff to it right now is
  79 a mistake before the operator chains.
  80
  81 ## 12:55
  82
  83 Ok, so `JVMNativeRegister` goes by for now.
  84
  85 ## 13:06
  86
  87 What I need to determine next is the best way to store the operation chains.
  88 I also need a way to minimal represent the entire state of the program with
  89 reduced memory usage. Currently I was planning to use a map which stored a
  90 value for each logical operation and its entire state. However, some states
  91 do not really differ from other operations. For example, if I just add value
  92 to the stack, there is only a single change which is that added value. So what
  93 I currently have would essentially copy the entire state when a small
  94 difference could be done instead. Although there would be a slight speed
  95 penalty, there would at least be less memory usage. It would be a very small
  96 amount of memory saving, but it could be just enough for it to be worth it. It
  97 also would not require massive redundent copies of everything also. Then with
  98 this state class for all the operations I can have the operator chains for
  99 all of the variables added also. Usually only a single instruction will
 100 change values, so I would not need to for example have all these copies of
 101 the same operator chain.
 102
 103 ## 13:14
 104
 105 Another thing to consider with operator chains would be to instead of having
 106 it such as `a = 2 + x + y + z`, it is instead `a = 2 + x`, `b = a + y`, and
 107 `c = b + z`. This way previous operator chains could be changed while still
 108 having the same value at the very end. When a calculation is performed and a
 109 value is written then the operator chain would drop down and potentially be
 110 replaced. So they must be mutable for those given operations.
 111
 112 ## 19:30
 113
 114 Yknow, `Arrays` and `Collections` have binary search algorithms, I should just
 115 use that to find things instead of inventing my own stuff.
 116
 117 ## 20:05
 118
 119 Actually I could do a form of SSA with `JVMProgramState` with the operator
 120 chains.
 121