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

> 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
  (JNIEnv * env, jobject recv, jbyteArray path)

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]:

Java_java_util_zip_ZipFile_openZipImpl (JNIEnv * env, jobject recv,
                                        jbyteArray zipName)
  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.




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

View raw message