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 15:41:00 GMT
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message