Appears this class unit code will work out nicely for its purpose.


Now I just need to verify classes before they are used, which should not be much of a problem at all. Generally the verification process will load other classes and make sure that stuff such as circular extends and such are not done. Other things would also be done also.


I could actually use JavaDoc for every single class and package.


Private method invocations use invokespecial because private methods are not inherited.


The can access check can likely go into ClassPath or similar. It needs every single class to be visible for the most part before access checks can be performed and such however. Well, generally the access check would be given two accessible objects. So this code can just go into the accessible object however static in interfaces is not supported. So there could just be an accessibility checker and such.


Personally, I wish fossil had a grep of sorts, however if I go back into the past far enough I should be able to find a canAccess variant. It should be in the lookup actually.


It cannot go into the class interface, it has to be in ClassPath. There is a need to lookup classes for protected and such to determine if something is an instance.


Thinking about the kernel for the test interpreter. Does the kernel run outside of the interpreter or does it run inside of it?


The interpreter remains on the outside. I also had a previous idea about having a deterministic interpreter. The deterministic interpreter could record and replay execution sessions. The interpreter would basically operate in lock-step with processes. The maximum number of JIPS would be maxJIPS * numThreads. Or there could just be a single area where code is executed and such. Access that goes outside of the interpreter into the host kernel would have to get recorded results, so this means that the kernel cannot generally do anything fancy with objects being executed (such as changing a local variable value). This means that all calls that go into the kernel (via the magic interfaces) would have given and returned values as such. Supporting such a thing would then require that the kernel use a different means and such for representing threads which do not use the host system based threads. Basically, to the running system a Thread would map to this KernelThread. On a JVM host the KernelThread would have Thread internally, but for certain systems say perhaps the NES the KernelThread will be specially formed for the given system.


So to the Kernel there would be no Thread at all used anywhere except potentially used in the implementation. This means I will need a KernelThreadManager although the kernel could do it itself for example in a kind of createThread for a process or similar. It would have to be figured out. Then this would mean that the currentThread call would have to determine the actual current thread being used using implementation specific means. So since KernelProcess is final, this means the Kernel gets all of the stuff needed for threads. Then with this, my potential delemma for handling threads and such is solved.


With this, I have to actually change how the sockets and the kernel processes work. With everything purely in an interpreter, locks on Objects are useless and do not really do anything at all. The sockets and such will have to be split off into userspace sockets in __squirreljme and such. The sockets when it comes to the kernel however would need to handle client side sockets. So the kernel socket code must be split away and such partially to handle these cases. Otherwise with the deterministic interpreter, there would need to be a complex interpretation setup to handle lock in the kernel itself. However, in the end this would be better because this means that user-space processes would not share Objects that the kernel has (even though they could be garbage collected together, sort of). A separation of objects in general would be more secure and can handle static things better. So really, an interpreter like the one I would have put into the Java SE kernel would not work at all. Then with the kernel interfaces for user space usage in __squirreljme the packets sent between processes can somewhat be recorded depending on the situation. The one issue I will run into however is, well actually it is not an issue. I was going to say that running the kernel might not be possible because code running on a host JVM could use __squirreljme classes, but if that was the case then that means the JVM and the interpreter to run is running on SquirrelJME itself.


And right now the light reflecting off Jupiter shines through my window. I do wonder though how long I will see the planet for.