assets/developer-notes/stephanie-gawroriski/2014/11/02.mkd

   1 # 2014/11/02
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 02:31
  10
  11 Annotations are complex and there are tons of them, so I need to figure out
  12 the best way to handle all of them, without going completely insane. I can do
  13 something similar to the constant pool type stuff. I could probably use
  14 annotations and such to describe the contents of an attribute. Doing it this
  15 way I could treat it like a simple structure of sorts. Luckily though,
  16 unhandled attributes can be skipped. I could create individual classes for
  17 each annotation and have it a form of data type. That is, the AnnotationInfo
  18 would have the basic what the thing is, the size, and the data. But then it
  19 could generate data information from input data if needed. There are 24
  20 attributes currently defined in the class file format. I believe an annotation
  21 which describes the form of the type would be best as it would simplify
  22 loading all of the information. Some of it could be used, some other parts of
  23 it might not be. Access to the attributes would be a bit slow, however they
  24 can be nicely created with their needed information in the KBF format or the
  25 intermediate linker form layout (before it gets written to KBF or some other
  26 format). Never really done something complex as this before, however I believe
  27 one can use annotations in annotations, although I do wonder if you can use
  28 them in arrays and if they retain their correct order. In the AttributeInfo
  29 class I should keep it to enumerations while having the struct stuff based off
  30 it as annotation enum elements. At least with a recursive structure form I can
  31 have it so I can nest very deeply when needed. Another thing that I must
  32 consider is unions vs structures. I need to see how deep the annotation stuff
  33 can go because it can be a structure or a union. Perhaps the best thing to do
  34 is have multiple arguments and a type specifier. There will also need a way of
  35 using forward and backward specifiers (array lengths followed by arrays).
  36
  37 ## 04:54
  38
  39 And suddenly looking at the apparent complexity of the StackMapTable
  40 attribute, this is going to be a gigantic mess. So it might be just better to
  41 use an enumeration and define a structure that is C-like then perform parsing
  42 of it based on the input text. It does not have to be anything super complex
  43 like C, just a sort of copy and paste from the class format document.
  44
  45 ## 05:23
  46
  47 Very expressive but it can work once it is all parsed, and this will allow me
  48 to read attribute structures without writing reading code for every single
  49 kind of attribute there is. Representing StackMapTable with annotations like I
  50 had planned before would have been completely horrible.
  51
  52 ## 06:25
  53
  54 Compared to the attribute StackMapTable, both RuntimeVisibleTypeAnnotations
  55 and RuntimeInvisibleTypeAnnotations are super complex and make StackMapTable
  56 look really easy to parse.
  57
  58 ## 06:48
  59
  60 Now that all of the attributes are defined, they must now be compiled into
  61 some structure form which could be used by the class loading code to determine
  62 the layout and how to actually read these.
  63
  64 ## 09:09
  65
  66 Had this idea for IPC and system calls, make all of it a UDP-ish SocketImpl
  67 where one can do unicasts and multicasts to other things. So each process has
  68 its own communication socket which it can use to communicate with something
  69 else. So to send the kernel a message saying to map a byte array in memory or
  70 to load a class, it can send a unicast message to the kernel from the process
  71 socket. It would all act on datagrams. Although the IPC may seem like
  72 overkill, it will ease porting between systems because they could vary greatly
  73 when it comes to system call capability. This would hide that very much, while
  74 potentially permitting virtualized containers where a userspace process can
  75 control a bunch of other processes and provide a fake feeling of power.
  76
  77 ## 09:16
  78
  79 Actually, using Channels which were added in Java 7 would be more efficient
  80 means of communication as there would be no split input output stream, as
  81 channels are usually combined. It also looks like the NetworkChannel stuff is
  82 not very assuming of IP networking. Looks like all of the network channel
  83 stuff is far superior and not dead locked to IP. This means when I do
  84 implement networking, all that stuff will be using the channel stuff at the
  85 core. So all of the IPC stuff, talking to the kernel will be a
  86 DatagramChannel. It might be simplest to just have a single thread
  87 communicating with the kernel, where each thread has its own channel. Doing it
  88 that way would simplify threads because they would not need to lock on system
  89 calls. A bonus which per-thread kernel communication channels, is each thread
  90 is unique in their communication. So if two threads are opening a file at the
  91 same time, and the kernel determines that they are truly two separate files,
  92 it can handle both requests at the same time that they are made. The channel
  93 being datagrams is efficient compared to streams as the stream would need
  94 lengths and such. One could connect the socket though to get a stream as
  95 needed, but that would end up being buggy as there would be strange ways of
  96 communicating to the kernel in a stream form. At least with reliable
  97 datagrams, in a virtualized environment, processes can go up to their
  98 controller (hypervisor?) which can mess around with system calls as needed. It
  99 could either forward the stuff or emulate a bunch of stuff. The one thing
 100 needed for that is sub process controlling. Since I am not going to do the
 101 clunky fork a new process, it could work. That is I am doing something like
 102 spawning a new thread, like Win32's CreateProcess or POSIX's posix_spawn.
 103
 104 ## 09:30
 105
 106 But, I need to write my struct handling code to manage reading input classes,
 107 but it is good sometimes to think ahead to the future once in awhile and plan
 108 ahead.
 109
 110 ## 10:05
 111
 112 Text editor crashed, but I need to mark internal use only classes and perhaps
 113 document a bit morethings.
 114
 115 ## 20:27
 116
 117 Added checks for member flags, however I must get into reading of struct forms
 118 now.
 119