Hi Will,<div><br></div><div>OK, I think I understand the problem, but I don't fully understand (especially with the patch you sent) the way you want to go. From what I read from you, we need to generate a libjvm.so file that will be loaded by libjava.so, itself being invoked by 'some' executable. Can this executable be some standard JNI code that uses JAVA_HOME or something to find libjvm.so? I think that's how HotSpot is bundled.</div>
<div><br></div><div>So to do this:</div><div><br></div><div>First, I'd rather not affect how the existing tools are being compiled. I don't want the GNU Classpath version to be affected by this change.</div><div>Second, I would create the tools/libjvm directory (like you did) to just contain the Makefile (and the magic version file?) to create the .so file. Is the libjvm.so file supposed/able to contain most, if not all, of j3?</div>
<div><br></div><div>Third I need to understand what do you think could be the launcher of that executable? Do we have to create one ourself?</div><div><br></div><div>Thanks!</div><div>Nicolas</div><div><br><div class="gmail_quote">
On Wed, Oct 26, 2011 at 9:34 PM, Will Dietz <span dir="ltr"><<a href="mailto:wdietz2@illinois.edu">wdietz2@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Oct 25, 2011 at 7:01 PM, Dietz, William Barrett<br>
<<a href="mailto:wdietz2@illinois.edu">wdietz2@illinois.edu</a>> wrote:<br>
> Inlined below (with some discussion).<br>
><br>
> Thanks!<br>
><br>
> ~Will<br>
><br>
<br>
</div>I've been working hard across the last day to try to either fully<br>
justify this, or to find an alternate way to make use of OpenJDK.<br>
<br>
I submitted the patches because this was the 'best' solution I came to<br>
earlier, however I don't like it one bit, and I imagine you're not<br>
especially fond of it either :).  Hence the need to come up with a<br>
compelling argument or an alternative solution.  Here I hope to do a<br>
little bit of both:<br>
<br>
Firstly, a little background (so we're on the same page).<br>
<br>
Like GNU Classpath, OpenJDK's runtime libraries are defined in various<br>
jar files as well as a number of native ".so" files.  Curiously,<br>
unlike the GNU implementation, OpenJDK's jar files never actually load<br>
the native files, namely libjava.so.  Instead, it's expected the JVM<br>
already has loaded libjava.so before using those jar files (see<br>
<a href="http://blog.fuseyism.com/index.php/2008/07/28/comparing-and-contrasting-vm-interfaces/" target="_blank">http://blog.fuseyism.com/index.php/2008/07/28/comparing-and-contrasting-vm-interfaces/</a><br>
for information/citation).<br>
<br>
Okay, no big deal.  Just dlopen() libjava.so (see "Hook<br>
JnjvmClassLoader" patch for the straightforward implementation of<br>
this) early on, and away we go.<br>
<br>
But wait! libjava.so needs some friends to be loaded, namely<br>
libjvm.so--where libjvm.so, as the name suggests, is a dynamic library<br>
that contains the JVM's interface to the runtime libraries (primarily<br>
through a number of JVM_* methods).  libjava.so even insists on having<br>
these JVM_* symbols have a particular version, otherwise it refuses to<br>
load at all.<br>
<br>
The approach I took in this patch (and the corresponding symbol<br>
versioning patch) was to wrap up enough of VMKit (mostly<br>
J3Classpath.a) into a libjvm.so (and masquerade it happily with the<br>
right versions) so that when libjava.so went looking for its libjvm.so<br>
it found and used our implementation.  After all, it would be rather<br>
nice for the runtime libraries to call into /our/ JVM not into the<br>
default libjvm.so, Hotspot :).<br>
<br>
That works, and these patches make that happen.  And I think it might<br>
even be the "right" way to do this, given all the above.  It's lame,<br>
but that's how things go sometimes.<br>
<br>
There is an alternative, however, and it makes different trade-offs,<br>
but might be more agreeable.  The idea here is what JamVM does when<br>
using it's own launchers ('jamvm', etc), although I can't find any<br>
documentation suggesting this is intentional: just let libjava.so load<br>
its own libjvm.so anyway, don't bother with our own libjvm.<br>
Interestingly, this works fine as long as we're careful to define all<br>
the entry points into libjvm.so (which should be the set of JVM_*<br>
methods, which means we already do this) due to the way symbols are<br>
resolved (dlopen()'d library won't override symbols defined in the<br>
calling process).  To be honest, I'd expect that with symbol<br>
versioning requirements, libjava.so would use those versioned symbols<br>
despite what the host process contains, however apparently that's not<br>
the case.  This is dirty for a few reasons, both because if relies on<br>
some tricky symbol magic (magic to me anyway, since versioned symbols<br>
aren't familiar territory for me) and because it counts on us<br>
essentially masking the loaded libjvm.so--if we miss one, the result<br>
might be a hard-to-debug mess.  I'd much prefer never having the<br>
hotspot libjvm.so in our process to begin with.<br>
<br>
I just changed the code (dropped this patch and the symbol versioning<br>
patch), ensured my JRE's libjvm.so was on the LD_LIBRARY_PATH (due to<br>
the way I have OpenJDK installed this isn't the case already) and the<br>
result works just as well as it did before (with respect with the<br>
subset of mauve I've been playing with).<br>
<br>
Given all this, I'm actually inclined to do this latter approach,<br>
because it requires fewer (no) changes to VMKit's<br>
organization/building, and simply because it seems to work fine.<br>
Additionally the libjvm stuff never played nicely on 64bit regarding<br>
relocatable GC object files--something I never resolved.  This dodges<br>
that.<br>
<br>
Anyway, hopefully that gives all this a bit more context and if<br>
nothing else can serve as a more useful discussion point :).<br>
<br>
Please let me know your thoughts when you get a chance :)<br>
<br>
Thanks for your time!<br>
~Will<br>
<br>
PS An an aside, eventually we probably *will* want to build *all* of<br>
VMKit into a libjvm.so so that we can drop it into an icedtea/openjdk<br>
installation and a)make vmkit more accessible to many people and<br>
b)leverage the tools/testing/etc from IcedTea (a java installation is<br>
more than the JVM, after all).  However that's a goal for later, and<br>
not a solution for the issues described here because our internal<br>
tools still need to work (vmjc, etc) and using OpenJDK's 'java'<br>
launcher won't help that.  But thought it might be worth mentioning.<br>
<div><div></div><div class="h5">_______________________________________________<br>
vmkit-commits mailing list<br>
<a href="mailto:vmkit-commits@cs.uiuc.edu">vmkit-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits</a><br>
</div></div></blockquote></div><br></div>