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

   1 # 2016/09/04
   2
   3 ## 14:51
   4
   5 One thing I can have is instead of PNGs for images, I can have a kind of
   6 vector format. SVG is complex and requires XML parsing however.
   7
   8 ## 15:34
   9
  10 One thing I need to consider is that with the register allocator if there is
  11 no state then I must store it into a jump target or restore it if it exists.
  12
  13 ## 15:49
  14
  15 I believe for the stack map state, I will need a local cache marker as such.
  16 Basically assign a unique value to a local and then for stack entries have it
  17 so it points to that local and store the unique value. When a local value is
  18 written to then the unique value is changed. Although really the opposite
  19 must occur. Local variables need to have a link to the stack items which
  20 contain a copy of the local. In the event that a local variable changes, any
  21 existing stack entries are to be copied via generated code. Across jump
  22 target bounds, I should clear the entries so their cached state is removed
  23 since it might not make much sense. There can be a jump from two places which
  24 has the same stack layout but where the value is sourced from two completely
  25 different locals. Then when a local value wants to change to another value,
  26 that check is performed to copy it to the stack.
  27
  28 ## 18:55
  29
  30 So I need to determine the best way to handle caching of stack entries.
  31 Perhaps instead of storing it in the local and stack treads they can be
  32 stored in the states themselves. It could essentially be a mapping of stack
  33 entries to locals for the most part. On entry of a new jump target, all
  34 cache entries will be invalidated for the most part. The thing to handle though
  35 would be the invalidation. I would then suppose that after each operation
  36 has been handled that it checks to see if the next operation or any jump
  37 targets would cause invalidation to occur. So the op parser will need to handle
  38 setting and handling of next jump targets.
  39
  40 ## 19:17
  41
  42 So actually, I will need to handle cache flushing whenever there is code that
  43 would land on a jump target somewhere. Flushing must be performed before the
  44 jump code is generated. I was about to write it following it. So if in the
  45 event no flushing was performed, and it should be flushed then it will be
  46 flushed in the basic handler.
  47
  48 ## 19:24
  49
  50 So yes, flushing if the next target is a jump target would be best and then
  51 handling flushing before a jump is performed (but after any conditions) would
  52 be best. Although it would not result in that optimized code, it should be
  53 good enough since most of the stack copies should be reduced.
  54
  55 ## 21:46
  56
  57 Another optimization I will have to handle is dup and such. Say a value is
  58 read from a value such a dup is performed. For swap and other operations these
  59 would actually cause copies when stack entries are not sourced from locals. So
  60 as such, I will need to have caching on stack values too. Flushing would have
  61 to do both, although stack items are always temporary.
  62
  63 ## 22:05
  64
  65 So next instruction to handle after a load is invoke of a special method.
  66 Special methods have a set of rules which change if the call acts just like
  67 a virtual call or it is an explicit method call. So as such, the linkage to
  68 use will vary. I suppose for simplicity if it maps to a virtual invoke that
  69 it will just the virtual invoke handler, while if it maps to a special one it
  70 will map to that. One thing to consider is that there will need to be multiple
  71 types of method references. So this means the global pool that is used will
  72 need method references for specials.
  73
  74 ## 22:09
  75
  76 I will need to check if such a call is valid and determine that during link
  77 time. Since at JIT time it will not be known if a method can call another
  78 method. Using the basic pool information it will need call source (the
  79 current method and class) along with the target method and the invoke type
  80 it uses.
  81
  82 ## 22:14
  83
  84 The generic pool of course can handle such things. I suppose to reduce the
  85 space complexity required to handle such things, I can have a reference to
  86 a method and then a call linkage associated with it. The call linkage has the
  87 from and to source and the type. So when a direct method reference is used it
  88 can point to the method data with its flags and such. Then the secondary
  89 linkage can use that information to determine if the call is valid or not.
  90 This way if a bunch of source methods end up calling a large number of methods
  91 there would be many duplicates of the source.
  92