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
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
Foo is processed, it will remain
Foo and not become
Then this means that, the constant pool can do rewrites now, which simplifies that.