5 Thinking about it, `JITExecutableBuilder` can be merged into the class stream
6 because the class stream just forwards everything to it anyway. This would
7 reduce the number of classes and indirection.
11 I wonder if my stack allocation should be exact before-hand, or after the
12 fact. It really does not matter, but I suppose it depends on the ABI. For
13 example if I setup the stack beforehand then it is possible that the kernel
14 can just plop a new stack right on top of the current stack. Maybe during the
15 middle of execution of this code, it can _virtually_ enter a new method. If
16 the stack of the current method is outside of the stack bounds then it is
17 possible the kernel would clobber the stack and destroy it if such events
18 occur. Also, programs like GDB possibly operate in this matter, by having it
19 where a new stack is temporarily overlaid on the current one.
23 I suppose a first thing I can do is perform no initial stack caching at all
24 and just do it in a completely naive way. When I do implement stack caching
25 though it should not require a rewrite of the code generation parts of the
26 JIT because the machine code parts would be standalone using simple move
31 I wonder if I should have flattened pointers that are only limited to a
32 32-bit address space. It would save some things when it comes to 64-bit for
37 It would be too complicated, in most cases any system with a 64-bit address
38 space will be using 64-bit registers. So I only need to consider the
39 integer values of a smaller size. I would also have to make sure the OS only
40 allocates in a given range so I can mask it in place. This would mean a single
41 4GiB pool of memory. Using bit shifting can be used, but then there is the
42 block alignment. So it is pretty pointless and complexicated.