08:34
I would suppose that processes should have their own unique structure manager which is derived from the top level structure manager provided by the kernel or interpreter. This way it is easier to tell which objects belong to a given process along with having each process have their own set of objects which can completley cleared when a process exits. The kernel itself can just use the host object manager for the most part.
08:39
However when it comes to objects and the kernel itself, there can be a kind of circularity so to speak. The field positions within objects are needed by the dynamic compiler and the static compiler to know where fields and methods are in relation to an object or class.
08:47
However, where I am going right now has to be adjusted. Currently all the
classes for a process would be reloaded along with their information. I need to
have it where a class could be derived from the kernel itself. So I suppose
what I need is a RuntimeClassPath which is very similar to ClassPath
except that classes provided by the kernel are shared among all processes. So
when a new class is requested it is not duplicated. Another thing to consider
are class units. Static class data does not really change much at all, just in
the dynamic linking information. I will need another similar thing to the
ClassPath except one that manages singular class units. So in the event that
a ClassUnit is shared amongst multiple processes, the information such as its
field alignments will already be known. The one thing that is not known however
would be the class base offset (for super classes).
08:54
So to think of it, perhaps when it comes to the kernel, the kernel should not
have a RuntimeObjectManager at all. The kernel can be completely oblivious
for the most part about how objects are laid out in memory. It just needs a
way to call the garbage requester when requested.
08:58
However, when it comes to the current layout the interpreter and the kernel
which uses the interpreter are completely separated. However the object
spaces are pretty much the same. So perhaps instead the RuntimeObjectManager
is given ClassPath. I remembers the class unit which contained a class. There
could then be a hierarchical layout to it. The kernel gets the root ROM and
then the processes get their own ROM as I stated before. However, to reduce
the duplication of ClassUnits in ClassPath they need to be shared.
Otherwise there can be pointless duplication of ClassUnits.
09:05
ClassPaths however can be combined from ClassUnits in a way where two
class paths could have a similarly named ClassUnit from a different provider.
The only way to tell them apart is if they are a different object (they are not
== to each other). So I suppose in this case I have a ClassPathProvider
which instead of using ClassPath to create sets of classes, the provider is
given the units and it returns the ClassPath instead. Then individual
ClassUnits and the classes contained in them can have implementation
dependent objects associated with them. So then this way, there should never
be a new of a ClassPath outside of ClassPathProvider. I could even make
ClassPath private so to speak and have it only be generated by the provider.
Then with a generic flag this can be used for object association. The
ClassPath would have wrapped class unit references. When a class is requested
each unit is checked for given class information. If object layout information
is requested (this would be the unknown special object) then the ClassPath
can determine which wrapped ClassUnit contains the given class and then
use the information in the given ClassUnit. After verification, the
ClassPathProvider can call a callback method which can initialize the
internal object reference. This way to the outside it cannot be set and appears
to be an immutable reference. The internal object initializer would already
have the memory accessor associated (for alignment and such) and it would then
calculate the alignment where all the fields should be. Then I would suppose
in the ClassPath there is another object association which knows about the
global CIClass specific information along with ClassPath specific
information. The information that is stored in the ClassPath instance could
be instead the base class alignment from the object base and the size of the
class. This way the internal field alignments only need to be calculated once
despite them being shared across multiple ClassPaths.
09:15
The compiler could also use the alignment information to determine where fields
exist within the kernel and such. The only issue is with the statically
compiled Kernel itself. I would very much like to have its CIClasses be
shared among the internal threads. So there would need to be some kind of
initialization that can be generated by the compiler which gives the location
and sizes of objects. So that for the most part, the CLDC classes are already
precompiled into the kernel.
09:21
However for that, the kernel would need precompiled CIClass objects. So
what I can actually do is have kernel internal offset information. The
compiler for every class which is internally represented would create a
virtual CIClass. The class would implement CIClass and contain all of the
internal kernel details. The compiler would just not create virtual classes
or all of the virtual classes (because otherwise it would create an infinite
amount of classes). Those virtual classes would exist but they could never be
forName()ed because they would not be in the kernel's run-time system. The
virtual CIClasses representing the classes which were statically compiled
will be combined into a single ClassUnit which returns them depending on the
requested class. Then when it comes to the alignment information, the same
thing will be done. These virtual classes would contain said information.
09:26
So basically, having the interpreter (even if it rerecords) appears to be the
incorrect route to take. The interpreter and its object space is completely
incompatible with native object spaces and how it actually exists. So I suppose
what I need instead is to write a simulator and then target that simulator with
the native compiler. Then when it comes to interpretation, completely ignore
the interpreter and drop it completely. Details of classes and such are already
fully handled to my knowledge. However, since I am on Linux PowerPC, I should
write a simulator which can run PowerPC Linux programs (such as say nethack)
first because there are simple binaries that can be tested. Once simple
programs are supported I can then go onto the native compiler, compile some
classes, then run the code in the simulator.
09:51
Instead of a rerecording interpreter, the simulator can support that instead. One thing that is needed would be a binary format support library for ELF, a PowerPC execution engine, and a Linux system handler (handles system calls and file system details).
10:04
I need to handle a recursive optional dependency and make sure that is not included.
10:58
I would suppose that the root in the simulator could also be a ZIP file which can be used to access files. This way on systems where it is not possible to represent a given host filesystem, it can at least be placed in a ZIP. However a file would have to completely be read in due to compression and cannot quickly be memory mapped. So a very large file attempting to be memory mapped will cause the file to be recreated on the virtual system or using some other means.
13:06
Some operating systems rely on block devices to provide filesystems, while others can use virtual file systems quite easily. Having a command line based configuration for a simulation sequence can get quite complex. So the question is, I need an easy to use configuration system that can provide the program and the required arguments to the simulator. This way when it comes to testing natively compiled SquirrelJME on the simulator a number of configurations can be used instead of having the test system specify the required command line arguments. This would in a way greatly simplify setting up the simulator and would allow for it to be extended by the configuration.
13:13
One thing which I should support is multiple processes that run under the simulator. It may be required by some programs that a new process is created or a fork is performed of an existing process. So I should support such a thing along with multi-threading.
13:30
Actually, the simulator is more like an emulator for the most part. However the environment that would be running in it would not be a drop-in replacement because Java ME for example lacks stdin which some systems have and may rely on.
13:36
Also, the system would be able to operate with no ROMs and generally will perform high level emulation of well behaved systems.
13:46
One thing I can also have is simulator groups. For example, I might want to test communication between a DOS system and a Linux system over a virtual serial port possibly, so as such the two systems should be able to communicate to each other in the simulated environment. There could also be a combined networking system connected to each system.