assets/developer-notes/stephanie-gawroriski/2016/08/17.mkd

   1 # 2016/08/17
   2
   3 ## 11:22
   4
   5 I should make it so some basic information can be gleaned from the triplet
   6 since on many systems ELFs will have the same code for the most part.
   7
   8 ## 13:15
   9
  10 I went for a walk. I determined that the constant pool needs to get some
  11 trimming performed. Currently all entries are written and unused ones just
  12 point to the null space. What I propose then instead changing the constant pool
  13 get into return a holder (then use `<Foo>as` on that) and then have it possible
  14 to activate an entry. Entries which get activated will then be assigned an
  15 index. Then this way, entries are ordered in their activation order. Also
  16 for the most part, only entries which are activated are stored in the final
  17 class. Since every class contains UTF-8 strings while the code generator as
  18 it stands does not use these, there will essentially be a large number of
  19 constant pool entries that waste space just pointing to the null element. Right
  20 now my binary is 81KiB, but since I am partially in code I will not be able to
  21 determine how it works in the end. However regardless it should work in saving
  22 space. Since the code wil be the most important aspect.
  23
  24 ## 13:20
  25
  26 Also, I am very likely to limit individual classes to 65KiB. This way there is
  27 no magic pointer shifting required. Also this is Java ME which is made for
  28 embedded systems. In general, most classes will be tiny so generally all
  29 offsets will be wasting for the most part two bytes.
  30
  31 ## 13:33
  32
  33 This also means that I will not need the null entry either.
  34
  35 ## 14:46
  36
  37 And after that work, these blank binaries are about 39KiB. So quite some
  38 savings removing pointless bytes.
  39
  40 ## 14:48
  41
  42 Technically classes are referred to by the namespaces, so the name of the class
  43 is duplicated for the most part. It might be reasonable for classes to be
  44 unnamed in the stream where the initial bytes indicates the name of the class
  45 although this could complicate some things.
  46
  47 ## 16:14
  48
  49 As previously thought of but dropped for simplicity and individuality of
  50 classes. I will likely backtrack and have a shared string and constant pool
  51 for namespaces. There otherwise would be quite a large number of duplicated
  52 strings in a namespace which would essentially just wast precious space. My
  53 goal is to have things as small as possibel, so this space wasting is rather
  54 nasty.
  55
  56 ## 16:17
  57
  58 However, I am kind of thinking about limiting everything to 65KiB. Everything
  59 from resources which are built-in (they would be compressed, so as long as
  60 the compressed data does not exceed that amount) to namespaces.
  61
  62 ## 16:20
  63
  64 However, I should write the generated code in a way where it would be simple to
  65 adapt to a global constant pool. However I should write it anyway since it
  66 would be much more compact. I can probably also remove the streaming support
  67 and just use the end directory for a given namespace. However, one thing I am
  68 not too sure of is how large the resulting code will be after everything is
  69 generated. So I should likely generate the code first.
  70
  71 ## 16:34
  72
  73 The symbols should not be equal to `String` because `String` is not equal to
  74 a symbol.
  75
  76 ## 16:40
  77
  78 I am going to do a current pool strategy and work with the pool through that
  79 since it would be the simplest solution. I can also have helpers for
  80 individual entries also.
  81
  82 ## 18:22
  83
  84 Actually I can have namespaces be a lower size yet not limit the namespaces
  85 to 65KiB by using shift values. It is a bit slower because they would have
  86 to be calculated, but it is not in the class data. With a forced minimal
  87 alignment of 4, I can shift 2 bytes away. This would limit namespaces to be
  88 262KiB. However, if I make the alignment 8 then namespaces would be limited to
  89 512KiB. However, would an alignment of 8 really save much space? However
  90 thinking about it, the next entry's position can be deterimined by the previous
  91 one's size. I can not have a namespace limit, but limit individual entries to
  92 be 262KiB in size. This would likely be the best plan.
  93
  94 ## 18:50
  95
  96 Although the greatest simplification would be just to limit the namespace size.
  97
  98