Etienne Gagnon wrote:
> 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.
Right, in the IBM VME world, the VM explicitly loads the hyluni.dll and
ICUInterface34.dll (a dependent DLL containing char functions used via
String).
> 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.
So you will see code everywhere like this [1]:
jboolean JNICALL
Java_java_io_File_existsImpl
(JNIEnv * env, jobject recv, jbyteArray path)
{
PORT_ACCESS_FROM_ENV (env);
...
}
Where PORT_ACCESS_FROM_ENV is a macro that expands out as follows [2]:
#define PORT_ACCESS_FROM_ENV(jniEnv) \
HyPortLibrary *privatePortLibrary = \
((HyVMThread *) (jniEnv))->javaVM->portLibrary
The portlibray is itself a function pointer table that contains
functions used in the JNI code.
> 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.
The only functions that are exported by the VM are [3]
VMInterface* JNICALL VMI_GetVMIFromJNIEnv(JNIEnv* env)
VMInterface* JNICALL VMI_GetVMIFromJavaVM(JavaVM* vm)
The remaining VMI functions are looked-up in a function table [4] in a
similar fashion to the portlib code, so for example [5]:
jint JNICALL
Java_java_util_zip_ZipFile_openZipImpl (JNIEnv * env, jobject recv,
jbyteArray zipName)
{
VMI_ACCESS_FROM_ENV (env);
PORT_ACCESS_FROM_ENV (env);
...
zipCachePool = (*VMI)->GetZipCachePool (VMI);
...
}
> 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.
That is the moral equivalent of what we have done, as shown above.
> 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.
We want that too, and I believe that it is already possible.
Regards,
Tim
Refs:
[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/luni/file.c?view=markup
[2]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/include/hyport.h?view=markup
[3]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/vmi/vmi.c?view=markup
[4]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/include/vmi.h?view=markup
[5]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/archive/zip.c?view=markup
> 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.
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
