2016/06/25

09:04

I would need temporary filesystem usage for output blobs and other resources.

10:54

To reduce the binary size I can have a single shared global index that contains constants and other references as such.

11:14

With combined blob tables however, all classes would have to use this given table. However, when it comes to using individual classes everything that exists in the table structure might not even be needed.

11:35

I would suppose that a blob of blobs containing class blobs and resources should be used. This archive would just be a part of the executable. It would essentially be a giant table of resource data and natively compiled classes in sorted order. The bootstrapping system would setup a base JVM which can run JVM, then JVM would setup a task for the launcher and the user uses that for interaction. The archive would just be a flat binary for the most part consisting of classes or resources in separated tables. I can then use a modified UTF-8 comparison of sorts against a String.

13:24

So now that I have basic output, I must work on the SSJIT which takes an input class and outputs a native blob. There will need to be some kind of architecture generation class that the SSJIT can use. Since this can vary on the system, I would suppose that the manifest should contain the class which is the JIT to be used.

17:17

Actually, what I need is that interface that acts as a factory for a given architecture. The CodeProducerFactory will be associated with an OS where it extends a base factory for the architecture. Then this way, I can have sub-variants of architectures (for example powerpc32+g4 for a PowerMac G4).

18:56

I kind of dislike inner classes.

19:01

One thing I can do for producers is allow there to be a potential branch when it comes to a producer. For example I will have the base PowerPC producer and then an operating system specific producer. This wrapper class will in the event its methods are not overridden, will instead the code generator of a variant instead to handle actions. The only consideration however is that it is possible for a code generator to call a method which is not implemented at all in the base class. So I could add this functionality to the base generator so it can perform an alternative generation path. I would likely need an interface and a class that has the same methods as the producer. Enabling this action will allow operating system producers to modify the behavior slightly for a given architecture. This can complicate and slow things down a bit since it would have to check if a given method has been replaced. One alternative however is to have a number of interfaces. Each interface would define something. In the base producer, basically what will be done is that it will implement every interface. Then instead classes can be placed which implement one of the given interfaces. If one object implements the interface then that is called, if it does not it goes to the next. If nothing implements it then the operation fails or falls back to a default.

19:06

So basically the ProducerFactory will just have an internal generator for the most part which can create a class which implements the interfaces as much as it can. Then this means that each method would have to be given the producer as the first argument so it knows how to call other methods for example. This would be quite flexible but it should allow slightly modified behavior which may be required. Since modifying the base producer for a given architecture can be complex and may interfere with any operating system, this would be a viable choice.