09:42
New day today.
10:24
I should make it so that JVMClass can temporarily be mutable (when it is
partially loaded) then once I am done constructing it, it can be made
immutable. I could then remove some data locks when accessing classes for
example. I could also split off instance related information and have an
instance state in the virtual machine also. Instead of having the interpreter
bits built into the JVM code, I can branch it off and have a base engine
for it. So essentially, I would be forking the code so to speak. Thus, what
I have now with the compiler bits will go into its own project. There would
only be things needed for loading classes and such, stuff which the compiler
can use but not what the interpreter should use. The compiler generally is
not going to need to create new instances of strings and create arrays and
threads for example, it just wants to pass through the code. This would also
act as separation which would be good too. If the interpreter engine needs to
be rewritten then there is no need to worry about interfering with the code
that is part of the compiler.
10:31
Also my list of errors is getting a bit cumbersome, so I need a better way to
store the dictionary of sorts. At least when moving the code over I will
potentially have to reassociate all of the error codes and prune them as
needed. However, the most likely case is that most parts of the current
interpreter namespace become part of the compiler base. Thus, performing these
changes should result in cleaner and better to maintain code. For the mutable
and immutable JVMClass variants, I will have a base class for classes and
then derive a partial and complete from them. The compiler will just know
about loaded classes, the interpreter would keep a cache of the classes as
they are loaded into memory (one which the virtual machine would expect).
15:27
When it comes to the error codes, I can use special JavaDoc tags and put the error codes in the method description where the error is thrown. Then I can write a script which reads source code and then extracts those error codes and places them into a list.
15:57
Would also have to do the same thing with class members too, so that they are mutable and can be partially loaded also.
16:06
I would suppose that the class loading code should be part of the base code.
17:44
Looks like Java 9 will be released later this year. But regardless of that, it is refactoring time.
17:50
Also instead of java-interpreter and java-interpreter-local it will just be
the former with the base class stuff split off as required.
17:53
I can also split off the code parser and the compiler core (the program stuff) from the base class loading stuff.
18:42
Now that the code has been moved, I just need to fix it all up with my new plan
that I have written earlier today. The first hurdle would be to fixup the class
file handler since it has at least 100 errors. However once the basic layout
is fixed and such, it should be better. When it comes to programs the class
file handler will just not touch that at all. Thus the program and the
class file support would essentially be standalone except the program needs
stuff such as the constant pool for example when the byte code and other things
are parsed. CFClass will be immutable and the class file parser will just
build it instead. The eventual fixup of the interpreter will have its own
notion of the class and its state. This way the class file code and the
program parser code remain cleaner and simpler.
20:16
This means the class file parser does not need locks at all.