assets/developer-notes/stephanie-gawroriski/2016/09/30.mkd

   1 # 2016/09/30
   2
   3 ## 11:07
   4
   5 The virtual project handler will need to in a number of cases wrap specific
   6 calls with virtualized methods. For example creating a new array will need
   7 to create an array type in the target form.
   8
   9 ## 11:31
  10
  11 Actually one thing I should do is rename the virtualized project so that it
  12 could actually be considered a project that can be launched by the build
  13 system. Then I could even potentially virtualize the virtualized project
  14 which may be a bit interesting.
  15
  16 ## 12:37
  17
  18 I will need to determine how classes are handled. I will need to actually
  19 generate `StackMap` and `StackMapTable`, but those are rather simple to
  20 generate. Well actually with this virtualizer, I can implement the code
  21 portion of the class decoder more since eventually all instructions
  22 needed will get generated. The virtualizer will be straight through for
  23 the most part.
  24
  25 ## 12:58
  26
  27 I will need to virtualize array classes also.
  28
  29 ## 15:20
  30
  31 Probably the only thing that will work and allow for throwing all of the
  32 objects would be if `VirtualObject` were to implement `Throwable`. This
  33 would mean that a stack trace would exist for every object that is
  34 created, so that is a bit slow. It would be great for debugging
  35 however. So to handle that, I will basically have it where each exception
  36 handler points to an area off the method which unboxes the thrown
  37 exception to an object and then jumps to the actual handler. Then this
  38 means that `athrow` becomes virtualized with a static. That is, it still
  39 generates a throw but it actually wraps it. One issue with that however
  40 is that I will need branching code to detect the exception type after it
  41 has been unboxed. So there will essentially be linear checks, but this
  42 could be handled by the unboxing code. I then only unbox when a class
  43 is found.
  44
  45 ## 15:26
  46
  47 So the code would basically look like this:
  48
  49         VirtualThrowable t;
  50
  51         if (t.isInstanceOf(SquirrelJME.classForName("java.lang.RuntimeException"))
  52         {
  53                 unbox();
  54                 goto(handler);
  55         }
  56
  57 ## 16:36
  58
  59 Thinking about the test system, I need tests that just run with no pass or
  60 fail since I need to make sure behavior is duplicated. Since fossil now has
  61 unversioned space, I can store the expected results in the repository now.
  62
  63 ## 16:52
  64
  65 I should make it so the executable namespace writer is far simpler than
  66 before.
  67
  68 ## 16:54
  69
  70 One thing that can be done is I can have that future buffer class code in
  71 another project and have the executable code rely on that. That could form
  72 the base for sections. Basically the executable writer would work in sections
  73 similar to ELF, PE, and other formats (they use .text and such for example).
  74 Then for symbolic linking between sections since some things might not be
  75 known, such as addresses, there will be future references. So basically there
  76 would be built a table of relocations in the local executable namespace.
  77