2016/09/10

08:07

Something that may be most efficient would be to have it where the JIT writers are essentially the description interfaces with some modified methods. However they still need to be bridged in some cases because the JIT will perform some basic register allocation.

13:41

For the generic JIT, I should move off the actual file output bits to another class rather than having it done in the classes themselves.

13:44

Another thing is that class flags can go in the global pool since many classes could share the same flags, but these are just a single bitfield which would cost a few more bytes to reference.

13:46

It might be easier to refactor the base JIT changes into a new JIT which I will call the basic JIT.

13:52

Requiring that something registered to the output have properties for later system property output usage, is a bad idea. It should be optional and if it does exist then they can be used accordingly. I do need a system property system that can be reused to initialize and setup the JIT without being helped by the operating system target information. Although I still have to solve this issue.

13:56

Basically I need a serialization and a de-serialization of the configuration data. So this means I should split off the immutable configuration and instead have a configuration builder. JIT specific parts would need to be initialized by properties which are serialized and de-serialized as needed.

15:02

One thing that somewhat needs to go is the cache system which writes to the disk somewhere, that can be handled by a JIT output system of sorts. Basically the JIT outputs namespace binaries as normal, then that cache can be read from when it is needed. Before this was part of the configuration system, however it no longer is a part of it. I suppose one thing I should do is have an actual package that handles the JAR cache system for compilation. That is, the AOT compiler for the SquirrelJME binary acts the same as if it were the JIT running on real hardware.

15:07

So JITCacheCreator goes away and instead I suppose somewhere in jit-base there is a cache selection system that can figure out what to use. It must be in the base because it should not pull in the entire JIT since one might not even be included at all.

18:05

I suppose JITNamespaceContent should instead become JITNamespaceBrowser and in jit-base. Then JITCacheManager can go away. Then the browser can be used to implement that functionality.

19:31

My sorted tree map does not work properly in a case.

19:50

And that is fixed.

19:51

One thing that could be handy is if JITConfig can have a cached class lookup depending on the key used, similar to the factory code itself.