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.


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.


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).


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.


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.


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.


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.


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.


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.


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).


I need to handle a recursive optional dependency and make sure that is not included.


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.


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.


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.


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.


Also, the system would be able to operate with no ROMs and generally will perform high level emulation of well behaved systems.


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.