When it comes to
VMInterface, there can be one that exists per process and
they could communicate with each other as such.
Class.getResourceAsStream() operates on the JAR of the specified class.
This means that I need a dummy class in classes where resources exist so
that I can read the actual resources.
I should have a general mascot service of sorts. All the mascots will extend the base class however the original high resolution images would be placed in an original class. Then this way I can have a somewhat shared means of finding images to use. The base resource lookup class can even handle decoding the hexadecimal data and providing a binary stream.
Mascot images could actually be provided with the
ServiceLoader so that a
format as required can be specified and such. Then the instances of the service
will be in the JAR so that
getResourceAsStream would work there.
Never figured that I would have refactored the mascot projects other than resorting.
I kind of just want to work on MEEP for a bit.
Then I can have some kind of interaction and I can take a break with Squirrel Quarrel when desired.
Actually going into this, the application management services does exactly what the launcher would need to do for the most part. So this means that my previous launcher idea was a bit flawed anyway. So for the most part with these interfaces, I will have to integrate them as such.
Actually one thing that I can do is have a host virtual environment. Unlike the kernel, this would run the bytecode on the host system. It would not be interpreted and use the pre-existing JVM. This would be a system that could be used for testing or having a basic feel of the entire system as a whole. Due to the requirement of there needing separated execution states, input JARs would be read and their classes modified so that they are in their own unique per-process (classpath) package.
This could actually work, it would be a kind of Para-Virtual Java Virtual Machine which would run on Java SE systems. It could theoretically run on Java 5 however the code uses try-with-resources so that would not work much. The PVM could implement SquirrelJME and I can work on it through that. Then once the class library is complete I can perform native ports. The ports would need minimal code to be implemented, so in theory I should never run into a TODO.
To think of it, with some adjustments on how classes are loaded the JVM has the
Pompek and Goldberg requirements for virtualization. The only thing that needs
adjusting is the classes which are used. When a class is loaded, the loader
will essentially rewrite all classes in the JAR so that instead are prefixed
with say for example
processid is a
specifier for a given process. Each process has its own
performs the translation as required. Since each class would be duplicated in
a process this would mean that they have their own set of static globals and
otherwise. Since all classes would be erased and replaced with the process
specific classes they cannot see this fact at all.
One thing I have to consider is that application management such as which JARs are available and such has to be common so that I can simply use the same code when it comes time for a native port.
This means that
javame-meep-swm instead will need to wrap some kind of common
interface which manages applications. These would definitely have to use the
unsafe interfaces and classes.
Ok, so when it comes to applications and such, there will be a
which provides a list of all JAR files which are available. This would be using
a system specific means of providing built-in and other such JARs. Another
thing that I need to do is make it so the
VMInterface is split and just does
not have a few hundred methods of varying function.
It will be called
I dislike large thunderstorms.
The power failed and it seems the battery attached to my UPS has not held a significant charge (it is 6 years old however). The battery generally should last about 10 years however, so hopefully it is not a lost cause. However with battery powered laptops, I am still able to program. Just program in silence for the most part.
Alternatively I can design the system interfaces first and get away with what ever I want with the PVM. Then when it comes to native ports, I can determine the best way everything fits together, such as having the kernel previously. This way I can design it comfortably when it comes to the PVM and instead no worry about having the native interfaces intermingled. It would duplicate the native port however, although by that time it would give me enough information to reliably create a good interface for natively compiled systems.
I saw something in the SWM interfaces about daemon applications. That could be useful in a way.
The loading of all the package information takes a bit on my system.
I can likely make the ZIP code faster by removing the structure bits. The structure is a nice and a bit faster way to read ZIP data. Also the singular read buffer could be replaced by a cached group of temporary buffers so that reading is a bit more efficient than usual. If multiple threads are reading a single ZIP then they must fight for the buffered data.
FileChannel supports reading from any position, while
will have to be locked to prevent multiple threads from changing the position
during a read.
If I do remove all the structure information and instead just use straight
arrays and such, then reading should be a bit faster. What I could do in
general is have it where pre-wrapped
ByteBuffers are available to be used
and read depending on the size that they are. However previously I did not very
large arrays and chunks to be allocated because they could be wasted. However
Reference and try-with-resources can give me a buffer of what I need.
So it would essentially be a wrapped
ByteBuffer in a way. Then hopefully ZIPs
will be read a bit faster. If I also perform bulk reads instead of individual
reads then there would be less locking being performed.
So the time it takes to run everything before:
So I want to get this down to perhaps 2s to read all of the package lists. If it takes 7 seconds on this (decade old) system then it might take 30 seconds on an even weaker system.
I can also rename the classes, so instead of
StandardZIPFile, it is just
ZipFile instead. I can also move off the inner classes and place them
outside of the interface also.