assets/developer-notes/stephanie-gawroriski/2019/06/13.mkd

   1 # 2019/06/13
   2
   3 ## 08:15
   4
   5 Okay so SummerCoat runs this code, but RatufaCoat crashes. On x86 it runs
   6 okay until it tries to intern a string and on PowerPC is breaks after
   7 garbage collection on a return.
   8
   9 ## 08:32
  10
  11 Okay PowerPC runs fine, so this means it is a byte swapping issue
  12 somewhere.
  13
  14 ## 08:37
  15
  16 Crashes on 32-bit and 64-bit x86 so definitely an endianess issue.
  17
  18 ## 09:38
  19
  20 I wonder if I write a UTF somewhere.
  21
  22 ## 14:23
  23
  24 Okay so there is an actual write to ROM, I wonder if it happens on big endian
  25 as well?
  26
  27 ## 14:24
  28
  29 Okay it does, just does not lead to a crash.
  30
  31 ## 14:44
  32
  33 Okay so what is being written to ROM ends up being the vtable. So what happens
  34 is that our vtable entry is read in. Then we do a ref count on it when we are
  35 done using it??
  36
  37 ## 14:48
  38
  39 Okay so this is an issue with `INVOKEVIRTUAL`, it seems that is is uncounting
  40 volatile registers. And looking at reference pushing I exactly see why. I am
  41 using a fixed base for values instead of the volatile get.
  42
  43 ## 18:03
  44
  45 I am going to add a very basic debug print which just takes two characters and
  46 a number.
  47
  48 ## 18:36
  49
  50 I believe returned values need to be ref-counted. Why? Because even if we pass
  51 an object to a method that is `this`, if it returns `this` then we will drop a
  52 count. And that is basically what the initial case for `jvmLoadString()`.
  53
  54 ## 19:14
  55
  56 So a garbage collection is happening. I do know the `byte[]` gets GCed but it
  57 seems the string is being GCed too?
  58
  59 ## 19:21
  60
  61 Okay so it seems that `jvmLoadString()` is returning `1`.
  62
  63 ## 19:25
  64
  65 I see no issue from the caller side, so it has to be from `jvmLoadString()`.
  66
  67 ## 19:29
  68
  69 Maybe the copy from return is incorrect?
  70
  71 ## 19:31
  72
  73 Okay this sequence tells me that we do have an interned string returned but it
  74 ends up returning the value 1 instead of the value we want to return. Which is
  75 a bit strange. I know previously I used return registers as temporary values,
  76 so is such a thing still happening?
  77
  78         NA 00104974
  79         NE 0010499c
  80         NA 001049c4
  81         Ls 0010499c
  82         GC 00104974
  83         Ga 00000001
  84         ST 00000001
  85         NA 001049f0
  86         NE 00104974
  87         NA 00104a34
  88         Ls 00104974
  89         GC 001049f0
  90         Ga 00000001
  91         NA 00104974
  92         Nf 00000001
  93         Na 00104974
  94
  95 ## 19:39
  96
  97 I believe I have an idea of what is happening. I am copying the value to the
  98 return register, but before I actually return from the method the code
  99 generator generates code which can run the garbage collector. And the return
 100 register is not valid after and invoke, it must immedietly return. So I do
 101 know that the GC is being called to cleanup the `byte[]` object and then some
 102 kind of code in there causes `1` to be set to the return register. So I need
 103 to copy the value much later and after all the cleanup has happened.
 104
 105 ## 20:13
 106
 107 So now I have another issue where it seems that the values passed to the
 108 object array are exactly the same index or similar. Or the access of the
 109 array is wrong? But the wrong access is unlikely maybe?