harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: VMI Questions
Date Tue, 28 Mar 2006 16:09:26 GMT
Etienne Gagnon wrote:
>>> 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?

Ah, ok.  So as you have probably seen, the versions in the Harmony SVN
are stubs that return NULL; hence the comment above not to copy the
stubs into the runtime layout.

The actual implementation are provided by the VM in a DLL loaded by the
Harmony launcher[1].  At launch time the DLL is loaded (and the VMI
functions globally exported).

There is a default directory and DLL name built into the launcher:
...
  char defaultDllName[] = "clearvm";
  char defaultDirName[] = "default";
...

and the user can override these with command-line arguments to launch a
different VM / specify a different VM DLL, like this:
	java -vmdir:<sablevm> -vm:<hyvmdll>

>>> 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...

Does that resolve it?

Regards,
Tim

Refs:
[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/launcher/main.c?view=markup


-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message