00:35
Instead of having a single class per instruction, I can always split it up into groups. Then this way I do not need to worry much about having tons of classes. However some operations may be more difficult to find. However, I would say that having less classes with more meat would be the better alternative than very slim classes. It would require switch statements in the classes though. Those 256 classes would count twords the total class limit I will be imposing on the VM. Right now I have 250 classes total in all of my sources (well, 250 .java files). Plus some nearby operations have similar function and such. It would also mean that the cache reference array is a bit smaller too (which can be a good thing). There would also be less potentially stale reference objects in memory also. So if I set the shift to say 4, then I only need 32 elements.
10:02
I do not actually need unique IDs for basic optimizations. I can just have an active stack slot so to speak which points to preallocated registers and such. So I will need a list of native registers and such.
10:26
I will need a kind of a virtual working system which is lazy. Basically I work with virtual registers which may be in locals or on the stack, then I determine operations which are to be performed on them in a linear sequence. When the registers go away (they are overwritten) then they are stored before they are destroyed. Probably do not need to store them when memory barriers are hit because these are just registers. So instead of generating code that just copies from one place to another, adds some values, then stores that result into a temporary. It is basically just:
- Read int value from local #4, push to stack
- Push 2 to the stack
- Add the top two stack elements (virtual stack, and virtual local #4)
- The result is stored on the virtual stack position.
The result will exist purely virtually and will not be stored by default in
most situations. However invoking a method will require that the value is
stored somewhere if it is not consumed by the method call. Well, actually I
might not even need to use the value at all. One could write byte code which
adds a bunch of values together and then just pop
s the result meaning it was
pointless. So even during method calls I do not store it. The only time I have
to actually calculate the value is if it gets stored into a field (instance or
static), called into a method, thrown, allocate a new object, allocate a new
array (possibly even multidimensional), entering/exiting monitor. If some
operator chains are simple say byte code adds 2 + 2 + v, I can just turn that
into 4 + v. So if a bunch of math is performed on operations, I only really
have to perform the work when it becomes visible to the outside of the method.
This can be used for optimization and removing the bulk of Java's stack like
nature and could result in smaller code being generated. It would require
however that the position of exception handlers and the stack map table be
known for optimal work. Because if values are calculated and it just turns out
they are never worked with because some exception is tossed... Well actually
if they are in a local they will stick around to excpetion handlers. So for
each possible local variable state exists, there has to be one for each handler
of exceptions. So it is possible that operator chains can be ambigious in
this event. So I will have to specially handle exception handlers and operator
chains. So I propose that if a local is written to when there is an actual
exception handler that is present, that the operator chain is calculated. If
there is no exception handler and then suddenly there becomes one, then all
the operator chains associated with local values are calculated and code is
generated for them.
Essentially this results in operator chains for register values, which can be used to determine how values are used and such.
I made a base class JVMNativeRegisters with stuff in JVMProgramOutput, so I could likely simplify things a bit. I could have special program outputters which can virtualize int/long/float/double operations if not supported. This would be needed for 8-bit and 16-bit systems where 32-bit integer math is not supported at all.
10:40
So implementing JVMNativeRegisters
and the related stuff to it right now is
a mistake before the operator chains.
12:55
Ok, so JVMNativeRegister
goes by for now.
13:06
What I need to determine next is the best way to store the operation chains. I also need a way to minimal represent the entire state of the program with reduced memory usage. Currently I was planning to use a map which stored a value for each logical operation and its entire state. However, some states do not really differ from other operations. For example, if I just add value to the stack, there is only a single change which is that added value. So what I currently have would essentially copy the entire state when a small difference could be done instead. Although there would be a slight speed penalty, there would at least be less memory usage. It would be a very small amount of memory saving, but it could be just enough for it to be worth it. It also would not require massive redundent copies of everything also. Then with this state class for all the operations I can have the operator chains for all of the variables added also. Usually only a single instruction will change values, so I would not need to for example have all these copies of the same operator chain.
13:14
Another thing to consider with operator chains would be to instead of having
it such as a = 2 + x + y + z
, it is instead a = 2 + x
, b = a + y
, and
c = b + z
. This way previous operator chains could be changed while still
having the same value at the very end. When a calculation is performed and a
value is written then the operator chain would drop down and potentially be
replaced. So they must be mutable for those given operations.
19:30
Yknow, Arrays
and Collections
have binary search algorithms, I should just
use that to find things instead of inventing my own stuff.
20:05
Actually I could do a form of SSA with JVMProgramState
with the operator
chains.