09:50
Appears this class unit code will work out nicely for its purpose.
10:30
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.
11:17
I could actually use JavaDoc for every single class and package.
15:31
Private method invocations use invokespecial because private methods are not
inherited.
18:34
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.
18:45
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.
18:49
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.
20:10
Thinking about the kernel for the test interpreter. Does the kernel run outside of the interpreter or does it run inside of it?
20:18
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.
20:24
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.
20:53
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.
21:46
And right now the light reflecting off Jupiter shines through my window. I do wonder though how long I will see the planet for.