Well, I can do my best to potentially keep memory usage to a minimum. Some targets I plan to support might not have enough memory for a JIT so they would be purely statically operated (and would likely not support loading JARs). That at least would make it so programs can still run on it, provided it is cross compiled. Using special tricks however, I could potentially increased the amount of memory there is at a cost of speed. For example I plan for everything to refer to handles. Using handles I can move the used data around if it is not locked. I could also compress the data using a simple huffman of sorts. If a GC occurs, for maximal memory usage on low memory systems, I can free a bunch of objects and then compress anything which is not used.


So for simplicity, I am going to go for parsing the exception and especially the stack map table. It would simplify verification and it would increase optimization because variables can disappear from the StackMapTable. When I say disappear I mean that the compiler can set the local to nothing in an exception handler to indicate that it is not used there. Then this way I do not have to constantly store values for created operator chains for locals which are not cared about if an exception is thrown.


Computer turned into a nice brick today.