If you look at the jump target for instructions, you can notice loops and such.


Thinking about it, I could have exceptions done separate from the jump sources. Then I can have a union list and cache it when exception data is loaded. This will reduce the complication that would be required when handling such things. The jump targets and jump sources would get additions to them. This would work out since I only have to worry about exceptions later on.


Actually with this new way of doing things, I can load classes faster and just have to worry about the translation parts as they are executed and/or compiled. So this would in fact result in slightly increased load times at the cost of execution time. However, the interpreter is not made for speed or standard execution, it is designed for recompilation.


Need to bring back the by index variable states since now it is used.


In idea for having the interpreter or compiled target against J2ME, the older versions, is that for filesystem handling I can still perform it and provide FileChannel access and such. It would instead operate at a speed reduction since seeking backwards is not really possible. Thus the FileChannel will cache parts of the file, log any changes, and then create a new file when closed or synchronized. Also with the verification state being combined with the stack top and such, I can instead do it in a single pass. The locals are done first, but the stack is placed after the locals. Before I would need a pass for the locals and the stack, but now it can be combined into one. The stack essentially will never drop down below the number of locals which are available.


Now to remove the program output and such.


So now I have enough of this new interpreter (which actually handles no instructions) where I can continue on and start making objects for things and such. Thus some verification will end up being lazy. Although at a slight speed cost, it should be easier when it comes to memory usage sort of when compilation is being performed. The partial program code could also be used for inlining potential too.


One probably less known thing about the VM is that .class on a primitive is syntactic sugar for Boxed.TYPE. I previously just did the primitive since I figured instead of adding a bunch of magic I could instead just detect or set the value of TYPE for boxed primitives. However magic would likely be the better route due to the interpreter and compiler.