>>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. > > It doesn't. The hyluni library code uses macros that expand out to a > function table maintained by the VMStruct as you elude to below. >... > The only functions that are exported by the VM are [3] > VMInterface* JNICALL VMI_GetVMIFromJNIEnv(JNIEnv* env) > VMInterface* JNICALL VMI_GetVMIFromJavaVM(JavaVM* vm)
Exactly. Now, these 2 functions are global. How does the hyluni
library resolves these two global references? As far as I can see, in
the build/install process, the hyluni library simply assumes that the
system's dynamic linker will resolve them assuming they reside in a
specific file. See build.xml:
<!-- Don't copy the VMI library. the one we build is a stub that is
replaced by a concrete implementation by the VM-implementor -->
<patternset excludes="*vmi*${shlib.suffix}*" />
Unless I am missing something?
>>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.
>
>
> We want that too, and I believe that it is already possible.
I am surely missing something...
Etienne
--
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
