Hello,
I've been thinking how we could achieve a better separation between
VM and classlibs. I've looked how the drlvm is currently built and
works with classlib: the most of dependencies are located in the
drlvm's VMI module, which is implementation of a native interface between
vm and class libraries.
I've did some investigation how VMI (implemented by drlvm) is currently
used by the class libraries. One of the examples is in luniglob.c.
The code does something like this (please correct me if needed):
Usage case #1 - luniglob.c:
- First VM calls luniglob::JNI_OnLoad(); while loading the luni.dll;
- The luniglob::JNIOnLoad calls VMI:GetInitArgs() to grab the command
line arguments
passed to VM. Then it does readClassPathFromPropertiesFile() which does:
. asks VM for java.Home property value via VMI::GetSystemProperties() call;
. reads bootclasspath.properties, composes the bootclasspath;
. returns the bootstrap class path back to VM by setting
its com.ibm.oti.system.class.path internal system proerty
with SetSystemProperties() call
The question here, if the purpose of that code is to set the
com.ibm.oti.system.class.path system property for JVM, why can't this be
entirely the JVM's job to parse bootclasspath.properties file and load the boot
classes as needed?
In this case we can probably avoid such extensive call exchange between VM and
classlib components and possibly reduce VMI api set
(I'm not sure if the VMI Get/SetSystemProperties calls are used anywhere else?)
Usage case #2 - libglob.c, archiveglob.c, filedesc.c e.t.c.
In many places class libraries are exercising the VMI api for two purposes:
(a) Get Port library
- If the port library is considered as a part of the class libraries, then
why the class libraries would obtain a pointer to the portlib from VM?
(Perhaps the same question could also be asked for ZipCachePool - it is
queried from VMI at zip.c file, while ZipCachePool is also part of class
libraries).
(b) Get VM local storage
- It seems VM local storage is being extensively used by the class libraries
to keep the JNI ID's cache. If this is the case, then why can't these
ID caches be organized per class lib module and kept as a part of
class libraries? Probably they could be initialized via JNIOnLoad() as well
without additional interaction with VM.
I'm sure there could be other usage examples which I'm missing :). But, anyways,
can I ask the class lib native code experts for some more
clarifications regarding the ideas behind the VMI interface and why it
couldn't be avoided?
I wonder if we could limit the interaction between VM and classlib down to the
Java interface defined by the kernel classes set, I guess it may
simplify life a lot
for other VM implementors who will eventually want to make VM's
working with the classlib (I remember there were questions regarding
VMI while porting SableVM as well [1]). What will be the cost for such
simplification?
Thanks,
Andrey.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL
PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
