10:02
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.
21:26
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.
21:40
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.
21:52
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.
22:09
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.
23:52
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.
23:56
Then this means that, the constant pool can do rewrites now, which simplifies that.