DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.
Annotations are complex and there are tons of them, so I need to figure out the best way to handle all of them, without going completely insane. I can do something similar to the constant pool type stuff. I could probably use annotations and such to describe the contents of an attribute. Doing it this way I could treat it like a simple structure of sorts. Luckily though, unhandled attributes can be skipped. I could create individual classes for each annotation and have it a form of data type. That is, the AnnotationInfo would have the basic what the thing is, the size, and the data. But then it could generate data information from input data if needed. There are 24 attributes currently defined in the class file format. I believe an annotation which describes the form of the type would be best as it would simplify loading all of the information. Some of it could be used, some other parts of it might not be. Access to the attributes would be a bit slow, however they can be nicely created with their needed information in the KBF format or the intermediate linker form layout (before it gets written to KBF or some other format). Never really done something complex as this before, however I believe one can use annotations in annotations, although I do wonder if you can use them in arrays and if they retain their correct order. In the AttributeInfo class I should keep it to enumerations while having the struct stuff based off it as annotation enum elements. At least with a recursive structure form I can have it so I can nest very deeply when needed. Another thing that I must consider is unions vs structures. I need to see how deep the annotation stuff can go because it can be a structure or a union. Perhaps the best thing to do is have multiple arguments and a type specifier. There will also need a way of using forward and backward specifiers (array lengths followed by arrays).
And suddenly looking at the apparent complexity of the StackMapTable attribute, this is going to be a gigantic mess. So it might be just better to use an enumeration and define a structure that is C-like then perform parsing of it based on the input text. It does not have to be anything super complex like C, just a sort of copy and paste from the class format document.
Very expressive but it can work once it is all parsed, and this will allow me to read attribute structures without writing reading code for every single kind of attribute there is. Representing StackMapTable with annotations like I had planned before would have been completely horrible.
Compared to the attribute StackMapTable, both RuntimeVisibleTypeAnnotations and RuntimeInvisibleTypeAnnotations are super complex and make StackMapTable look really easy to parse.
Now that all of the attributes are defined, they must now be compiled into some structure form which could be used by the class loading code to determine the layout and how to actually read these.
Had this idea for IPC and system calls, make all of it a UDP-ish SocketImpl where one can do unicasts and multicasts to other things. So each process has its own communication socket which it can use to communicate with something else. So to send the kernel a message saying to map a byte array in memory or to load a class, it can send a unicast message to the kernel from the process socket. It would all act on datagrams. Although the IPC may seem like overkill, it will ease porting between systems because they could vary greatly when it comes to system call capability. This would hide that very much, while potentially permitting virtualized containers where a userspace process can control a bunch of other processes and provide a fake feeling of power.
Actually, using Channels which were added in Java 7 would be more efficient means of communication as there would be no split input output stream, as channels are usually combined. It also looks like the NetworkChannel stuff is not very assuming of IP networking. Looks like all of the network channel stuff is far superior and not dead locked to IP. This means when I do implement networking, all that stuff will be using the channel stuff at the core. So all of the IPC stuff, talking to the kernel will be a DatagramChannel. It might be simplest to just have a single thread communicating with the kernel, where each thread has its own channel. Doing it that way would simplify threads because they would not need to lock on system calls. A bonus which per-thread kernel communication channels, is each thread is unique in their communication. So if two threads are opening a file at the same time, and the kernel determines that they are truly two separate files, it can handle both requests at the same time that they are made. The channel being datagrams is efficient compared to streams as the stream would need lengths and such. One could connect the socket though to get a stream as needed, but that would end up being buggy as there would be strange ways of communicating to the kernel in a stream form. At least with reliable datagrams, in a virtualized environment, processes can go up to their controller (hypervisor?) which can mess around with system calls as needed. It could either forward the stuff or emulate a bunch of stuff. The one thing needed for that is sub process controlling. Since I am not going to do the clunky fork a new process, it could work. That is I am doing something like spawning a new thread, like Win32's CreateProcess or POSIX's posix_spawn.
But, I need to write my struct handling code to manage reading input classes, but it is good sometimes to think ahead to the future once in awhile and plan ahead.
Text editor crashed, but I need to mark internal use only classes and perhaps document a bit morethings.
Added checks for member flags, however I must get into reading of struct forms now.