2016/08/17

11:22

I should make it so some basic information can be gleaned from the triplet since on many systems ELFs will have the same code for the most part.

13:15

I went for a walk. I determined that the constant pool needs to get some trimming performed. Currently all entries are written and unused ones just point to the null space. What I propose then instead changing the constant pool get into return a holder (then use <Foo>as on that) and then have it possible to activate an entry. Entries which get activated will then be assigned an index. Then this way, entries are ordered in their activation order. Also for the most part, only entries which are activated are stored in the final class. Since every class contains UTF-8 strings while the code generator as it stands does not use these, there will essentially be a large number of constant pool entries that waste space just pointing to the null element. Right now my binary is 81KiB, but since I am partially in code I will not be able to determine how it works in the end. However regardless it should work in saving space. Since the code wil be the most important aspect.

13:20

Also, I am very likely to limit individual classes to 65KiB. This way there is no magic pointer shifting required. Also this is Java ME which is made for embedded systems. In general, most classes will be tiny so generally all offsets will be wasting for the most part two bytes.

13:33

This also means that I will not need the null entry either.

14:46

And after that work, these blank binaries are about 39KiB. So quite some savings removing pointless bytes.

14:48

Technically classes are referred to by the namespaces, so the name of the class is duplicated for the most part. It might be reasonable for classes to be unnamed in the stream where the initial bytes indicates the name of the class although this could complicate some things.

16:14

As previously thought of but dropped for simplicity and individuality of classes. I will likely backtrack and have a shared string and constant pool for namespaces. There otherwise would be quite a large number of duplicated strings in a namespace which would essentially just wast precious space. My goal is to have things as small as possibel, so this space wasting is rather nasty.

16:17

However, I am kind of thinking about limiting everything to 65KiB. Everything from resources which are built-in (they would be compressed, so as long as the compressed data does not exceed that amount) to namespaces.

16:20

However, I should write the generated code in a way where it would be simple to adapt to a global constant pool. However I should write it anyway since it would be much more compact. I can probably also remove the streaming support and just use the end directory for a given namespace. However, one thing I am not too sure of is how large the resulting code will be after everything is generated. So I should likely generate the code first.

16:34

The symbols should not be equal to String because String is not equal to a symbol.

16:40

I am going to do a current pool strategy and work with the pool through that since it would be the simplest solution. I can also have helpers for individual entries also.

18:22

Actually I can have namespaces be a lower size yet not limit the namespaces to 65KiB by using shift values. It is a bit slower because they would have to be calculated, but it is not in the class data. With a forced minimal alignment of 4, I can shift 2 bytes away. This would limit namespaces to be 262KiB. However, if I make the alignment 8 then namespaces would be limited to 512KiB. However, would an alignment of 8 really save much space? However thinking about it, the next entry's position can be deterimined by the previous one's size. I can not have a namespace limit, but limit individual entries to be 262KiB in size. This would likely be the best plan.

18:50

Although the greatest simplification would be just to limit the namespace size.