2016/03/26

02:06

For stack entries, I need to actually hide when the stack grows a bit too small, since currently they are treated like locals.

16:12

Was mowing about 2 acres of grass. Anyway, I have an idea for semi-whole program optimization when it comes to fields. When I load a class I need to have it so that partially loaded classes can be read. Then if global field optimization is enabled, I look in the partially loaded set of classes to see if one matches the field the class is in. If it is found, then the flags and potential constant value of the class determine if the value is treated as constant or not. By default if it is not enabled then fields in other classes would be treated as always volatile, while fields in the current class are treated with their respective flags and values. I have to watch when loading classes though, that I do not fail if the dependent class is malformed. I would have to catch the JVMClassFormat error and then just default to the volatile state. Also, to prevent failing classes from loading again I can put in a list of failed classes which are not in the classpath at all. That way they are never retried over and over again.

19:02

One thing though is that there has to be checking whether the operations flow correctly when they go from one set to another. I could actually be smart about it and put the code in the program state atoms and such. Doing it that way would also mean I can easily handle the metadata also without having the metadata handling code everywhere. So I would essentially perform a virtual not yet done push to the stack of the current atom to affect the next atom. If the next atom has state set for it and has variables then it is made sure that the given state would still be valid. So essentially, do a virtual pop of of the stack (does not actually change the state), then perform the operation of it where the result is stored in the target atom. If the target atom has state then it must match (except for the operator links). This I suppose would be the cleanest way to handle the operator links, since having that code in all of the byte code handlers would be very messy and error prone.

19:10

Actually looking at my code, the previous slot for the previous operation is incorrect.

21:32

Thinking about it, I wonder what would be the cleanest and efficient way to do what I wrote previously about performing operations on the next of state. Perhaps I could use internal temporaries of sorts, however those might not be needed at all because the operator links are just virtual. If for example dup is called which duplicates a stack element, then it just copies the operator link without requiring temporary variables at all. Thus the code generator would be smart enough to know that no actual work has to be done for said operations. The stack contains most of the work however. So I suppose a method which contains the operation to perform which also pushes the result to the stack with the correct operator links and such. Then later on when store needs to be done, the opposite effect. The only operation which really takes from the locals and stores a value back in without using the stack is iinc (which can also be used as an explicit add). So initially the first method will be essentially operatorLocalToStack which reads a local, performs an operation, and places the result onto the stack. That seems simple enough. Then it can check the target atom to make sure that it has the correct state and such specified (that is, it would result in the same stack if it is explicitely set).