Etienne Gagnon wrote:
Also, I would like to think about the VMI with the view of a "pure" virtual machine implementor, not that of a binary compiler implementor or that of a hybrid system implementor. It would just be more fun for me. I already don't like much working on VMI and class libraries; I might as well try to make it as enjoyable as possible.
That makes sense.. i.e., if you want to make it into something of a research project to define the best possible Java/VM API then I'd be interested in that as well. Of course this will take more work. First of course is defining what the goals and priorities are (if your goal were to do it quickly, then re-using the existing Classpath API would be the best option imho). In any case, there is lots of remaining Java code lying just above this API to be written. Doing so will naturally bring up those questions about the right way to define the VM API. Do you have any general guiding thoughts? E.g. we both agree that doing stuff in Java whenever possible and reasonable is better. What else? Some interesting areas to think about.. - Class loading. Can maintenance of initialized and/or derived types trees be done in Java? Loading constraints? Etc. - VM private data structures: could more of these be stored in byte[] arrays, so that Java code can just pass the byte[] array to native code where appropriate? - Class initialization: SableVM already does this in Java I think. - Threads - Exceptions - Stack walking - GC: any Java possibilities here? - Bytecode verification The more you "push down" the more it starts to get into the "VM written in Java" concept a la Jikes RVM. Another idea: the VM API is just POSIX (or some subset), and you have some way to manipulate (pack/unpack) C types via Java. Yet another idea (from JCVM): mix/embed C code in Java code analgous to the way GCC's asm() statement embeds assembly into C code, then auto-gen all the VM's native methods. "Etc." -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
