Hi, sorry if this is a bit long, my fault for not catching up with the list for a few days ;-}>
headlines are: * Cross-platform and language support - ltdl vs dlfcn - native code needed to access native code, jikes boot strap system - Java based loader? * In-lining of code - let the JIT do it * native code storage for JIT use - how much information is needed to allow good optimization? [cross-platform support] First of all thanks to David Tanzer, having something solid to start from makes a tremendous difference. The code captures a basic functional spec for a component loader very well. I'm not very familiar with UNIX dynamic libs so if this is way off please say; It seems dlfcn is quite platform specific; would ltdl make more sense? It seems as though only one 'native method' is provided per file this way, is that just for the demo code or is it a limitation of this method? Am I right in thinking that to use the table of 'native method' pointers we will have to place the operands on the stack and then jump to the method (just checking as the code to do that would also be a component and so how would we bootstrap it, jikes had a clever method involving writing from a JVM a startup JVM image with the native code in it)? Could this be implemented in Java so long as a native call mechanism existed to 'register' components with each other, there is probably no compelling reason to do this but it might improve cross platform support. [Code-In lining] To have a JIT we must have a method of storing 'compiled code' and calling it we could create the basic components as native code stored in the JVM using same system as the JIT. The class loader could then mark inside the byte stream a call to this native code in place of the original byte code. Or the interpreter could act as though the byte code should be interpreted as a call to that method. If this is too inefficient then the JIT will compile the method that the call is within and at this point may well decide to in line the code from the method call. I don't see why we would want to or need to create a different in lining method for these aspects of the interpretor. If we are using the boot strapping method like jikes then maybe some methods should be JIT'ed before the image is written. [native code storage for the JIT] I've never tried to create a JIT, but I assume we need to consider some way of describing the side-effects of a section of code; i.e. what registers are changed/used as input and output. Or do JITs not normally need this as they compile whole methods and so use the stack for data in and out and assume all registers are dirty? Thanks in advance, Peter
