Hi Weldon, I've started reading about the VMI. While my initial goal would be to get SableVM to work with Harmony as a drop-in replacement for IBM's VM, I have some questions about some assumptions of the VMI.
In particular, I would like to understand the motivation for the implicit direct link from the hyluni library to the VM library. In other words, it seems logical to me that the VM library would cause the dynamic loading of the hyluni library. On the other hand, I don't understand why the hyluni library assumes that it will be necessarily loaded by a specific VM library sitting in a particular directory. This assumption has an important side effect. The hyluni library assumes that it can simply call VMI_* global functions which are resolved by the dynamic linker. Personally, I would have done things some other way; I would either have had the VM library call a VMI_SetVMI() function exported by the hyluni library and requested the the VM library call it, or, better, I would have done like the debug interface and requested the VMI function table through the GetEnv function of the invocation interface : (*jvm)->GetEnv(jvm, &vmi, VMI_VERSION_1); This would seem the cleanest approach to me. The only problem is to avoid clashing with Sun's constants. The problem I see, with the current approach, is that it makes it impossible to provide distinct VM libraries for different purposes (debugging, faster execution, profiling, ...), as they can't be all in a single file. Etienne Weldon Washburn wrote: > ... In any case, feel free to borrow parts of kernel_path that > make sense. Also, feel free to ask questions about it. -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
