__ClassDecoder__ is getting a bit big since it triggers the class
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
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,
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.