Looks like __ClassDecoder__ is getting a bit big since it triggers the class size warning.


I can perform some basic and minor optimizations by caching some stack values using a simple and naive means. When it comes to saving/restoring values I can just lazily allocate a bunch of stack items for the number of local and stack variables.


So what I need is a generic class output system where I can write machine code into.


I suppose for simplicity that the JIT will treat the stack and locals as a single unified set of registers. Registers can be translated to stack machines as needed. Personally Java should have just used registers from the start instead of using a stack machine. However, I just need an efficient stack cacher.


Took a walk, was rather hot. However, I determined that a single straight through parsing can work but it would needlessly complicate how the JIT would work. There could be areas of code that goto to a later portion of code where I would have no idea what type of values are in variables, then that code could goto back to that unknown area. So I would need to defer handling. Then there are also exceptions and the stack map table to consider also. However, I already have a bunch of the code reading, exception handler parsing, and StackMap parsing code somewhere in history. I just need to find that history and then carefully import that code in.


Ok, so I need to merge work from multiple revisions:


So one thing to consider is...


...to keep the code simple. Before I had a complex cache system which was convoluted along with megaswitches and code all over the place for handling byte code operations. Since many operations are the same, I need to have a kind of simple dispatch that is not slow at all yet very simple. I suppose what I can do, like I have thought up of previously, have a kind of micro-op where instead of having clunky CISC like operations, they can be condensed into simple move operations and actual work operations.