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]