I will need to keep an eye out for division and remainder following each other in cases where the native architecture does both at the same time.


JITStaticCallRewrite would likely be better if it just rewrote the actual used class, this would simplify the constant pool intialization and it would also have the effect of having the ability to have instances of changed classes also. So it renames all instances of a given class.


I suppose in the simulated environment, for simplicity so that stuff such as field name collisions and such can be handled, for the most part just prepend a prefix to everything. Then to simplify handling of cases where one calls hashCode() and has a string called "hashCode", just duplicate every entry in the constant pool. Also, when it comes to LDC on a string in the constant pool, duplicate entries a third time for each string where LDC on strings is rewritten to something else. A problem however is that ldc is two bytes wide while getstatic is 3 bytes wide. So it cannot trivially be translated. Strings have to be rewritten however. There is also the case of string being rewritten to refer to itself also.


Actually with just plain class rewrites, I do not need a wrapper class for the constant pool, so I can just use it directly as such. Before I would have needed to handle cases where a class is referred to and such. So just renaming the class simplifies things.


Not sure if I want to write the pool first or later. Writing it I will need to know if there are any rewritten imports though.


Although thinking about it, rewriting could only be enabled if the class name being rewritting is not itself. So if Foo is being rewritten to Bar then when Foo is processed, it will remain Foo and not become Bar.


Then this means that, the constant pool can do rewrites now, which simplifies that.