On Tue, Jul 20, 2010 at 6:36 PM, Joshua Warner <span dir="ltr"><<a href="mailto:joshuawarner32@gmail.com">joshuawarner32@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div class="gmail_quote"><div>Sure, that's one major strength of LLVM: we could decide on a runtime function (CallVirtualMethod) that will get lowered depending on the underlying VM. I don't see any difficulties in accomplishing this.</div>
</div></blockquote></div><div><br>Is it common practice to emit function calls that are expected to be lowered by a later pass? I know LLVM uses this kind of thing with intrinsics (llvm.gcroot, for instance), but a pass lowering calls to specific functions seems very... messy.<br>
</div></div></blockquote><div><br></div><div>It is not lowering calls to specific functions but emitting a virtual call: we could decide to have a runtime call (ie that will get lowered) to get the virtual table of the object and put the indirect call instruction in place (ie it will not get lowered). Or a single runtime call that will get lowered to both getting the virtual table and do the indirect call.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
<br>What about something like a --emit-unlowered-llvm option on llcj that just spits out the LLVM IR before running this lowering pass?<br></div></div></blockquote><div><br></div><div>Yes, that's what I had in mind. llcj is just a driver here for VMKit, the real executable is vmjc, to which you can give a number of passes, including your pass that will lower your virtual call.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote">
<div><br></div><div>LLVM is capable of generating dwarf/unwind tables at compile-time (and also in a JIT environment), so you should get access to these tables in a standard fashion. The only caveat is that you need to change VMKit and they way it compiles exception handlers and exception checks.</div>
</div></blockquote></div><div><br>Could this be another case for emitting calls in the IR that are lowered by a later pass?<br></div></div></blockquote><div><br></div><div>This is much more difficult, but we could try to have something like that. On the list of difficulties: where is the exception handler IR located? who references it? how to prevent dead code elimination to remove it?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Avian only needs a 1-word header - it uses the lower bits of the vtable pointer for GC and hashing.<br>
</div></div></blockquote><div><br></div><div>Cool. And on a synchronized, it pushes the header on the stack? Or Avian is not multi-threaded?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div> </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div>
<div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">* Able to output object files (preferably) or assembly for the target platform, with appropriate global symbols for functions, etc. to be linked as a boot image.<br>
</blockquote><div><br></div></div><div>VMKit already does that, thanks to LLVM code generators.</div></div></blockquote></div><div><br>I was more concerned with whether this is what the llcj driver does. <br></div></div>
</blockquote><div><br></div><div>Yes, llcj can generate assembly files, dynamic libraries, object files, executables, etc.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>On the VMKit side, I'd be worried about the implications of adding extra steps in the compilation process, particularly if their only purpose is supporting another VM.</div></div></blockquote>
<div><br></div><div>VMKit is framework-driven, so we won't mind extra steps in the compilation process, especially if it ends up demonstrating the modularity of VMKit. And I would love to be able to specify on the command line what kind of object header I want, what kind of exceptions, how to implement virtual calls and optimize them, etc. All of these would be implemented as LLVM pass.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div> Personally, if I were a VMKit developer, such a feature would be high on my list of things to remove, unless such a feature turned out to be useful in other ways. </div>
</div></blockquote><div><br></div><div>Bare in mind that VMKit is research- and framework-driven. For run-time execution of VMKit, performance is always important, so we have to be careful (but adding LLVM passes does not cost at all). For ahead of time compilation, we should aim at having something the more generic as possible.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Is this a feature that could genuinely improve VMKit, or do you see this as something that would only end up being used with Avian? <br>
</div><div><br></div></div></blockquote><div><br></div><div>It will definitely improve VMKit. It may end up only being used with Avian, but at least it opens more opportunities.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>It sounds as if the big sticking point is support for 64-bit linux. It wouldn't be all that bad to require cross-compiling all AOT Avian builds from a linux machine (not worrying about building on windows), but I don't think I could justify supporting *only* 32-bit linux as a build platform. 32 bit systems are on their way out.<br>
<br></div></div></blockquote><div><br></div><div>64-bit linux is near to being fully supported. There is little code in VMKit (except the GC) that is arch-dependent.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>Just to be clear, I do fully intend on using llvm - the only question is what I use to compile class files down to llvm IR (or directly to native object files).<br></div></div></blockquote><div>
<br></div><div>Using the vmjc tool in VMKit and LLVM lowering passes seems like a nice option to me.</div><div><br></div><div>Nicolas</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><font color="#888888"><br>Joshua<br> </font></div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div><div></div><div>
<div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><font color="#888888">Joshua</font><div><div></div><div><br><br><div class="gmail_quote">
On Tue, Jul 20, 2010 at 9:07 AM, nicolas geoffray <span dir="ltr"><<a href="mailto:nicolas.geoffray@gmail.com" target="_blank">nicolas.geoffray@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hi Joshua,<div><br></div><div>What plans did you have for GC? No GC at all or Avian JVM has its own GC (and is it precise or not?)?</div><div><br></div><div>If you're not planning on using VMKit's GCs, then 64-bit system should not be a big problem: the only problem that we have now is compiling GNU Classpath, and most probably Avian JVM has its own version of the class libraries?</div>
<div><br></div><div>Also, note that platform support will be strongly dependent on LLVM support.</div><div><br></div><div><font color="#888888">Nicolas</font><div><div></div><div><br><br><div class="gmail_quote">
On Tue, Jul 20, 2010 at 4:41 PM, Joshua Warner <span dir="ltr"><<a href="mailto:joshuawarner32@gmail.com" target="_blank">joshuawarner32@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">Hi Nicolas,<br><br>Thanks for all your help, but if 64-bit systems are still a big problem, perhaps the VMKit AOT compiler is not the best solution to my problem. I'd like to be able to support the major (if not all all) platforms that the Avian JVM supports - x86 & x86_64 linux & windows, powerpc darwin and ARM.<br>
<br>Regards,<br><font color="#888888">Joshua</font><div><div></div><div><br><br><div class="gmail_quote">On Tue, Jul 20, 2010 at 8:00 AM, nicolas geoffray <span dir="ltr"><<a href="mailto:nicolas.geoffray@gmail.com" target="_blank">nicolas.geoffray@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">Hi Joshua,<div><br></div><div>If you can get a running 32bit system, I'd suggest you do so, as you'll get up to speed right away. I can't test VMKit on a 64bits machine, and I have been aware that there are some compilation/execution problems. Besides, the current GCs of VMKit do not work on 64bits (neither MMTk nor GCMmap2).</div>
<div><br></div><div><font color="#888888">Nicolas</font><div><div></div><div><br><br><div class="gmail_quote">On Tue, Jul 20, 2010 at 3:56 PM, Joshua Warner <span dir="ltr"><<a href="mailto:joshuawarner32@gmail.com" target="_blank">joshuawarner32@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hi Minas,<br><br>I tried recompiling Classpath with -fno-omit-frame-pointer, and now, instead of printing an error message, j3 just segfaults in <br>"j3::JnjvmClassLoader::loadClassFromAsciiz(char const*, bool, bool) ()"<br>
<br>I ran llcj under strace and found that it is not even opening the input or output files, but is otherwise running normally.<br><br>Updating to the latest SVN version (revision 108831) didn't change anything (I was only a few days out of date).<br>
<br>I'm not sure where to go from here. Does this fit with any of the known problems under 64-bit linux?<br><br>Thanks,<br><font color="#888888">Joshua</font><div><div></div><div><br><br><div class="gmail_quote">
On Mon, Jul 19, 2010 at 4:45 PM, Minas Abrahamyan <span dir="ltr"><<a href="mailto:minas.subs@gmail.com" target="_blank">minas.subs@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">Hi Joshua,<br>
<div>> $ j3 Hello<br>
> j3: JavaClass.cpp:480: j3::JavaObject* j3::Class::doNew(j3::Jnjvm*):<br>
> Assertion `(this->isInitializing() ||<br>
> classLoader->getCompiler()->isStaticCompiling()) && "Uninitialized class<br>
> when allocating."' failed.<br>
> Aborted<br>
<br>
</div>Regarding to j3 in 64 bit version, it should work now after we've<br>
found crush reason,<br>
both in Debug and in Release versions. (and its 32 bit version was<br>
continuously working)<br>
<br>
But your case is something strange, crush didn't type such messages.<br>
Have you taken VMkit from svn and latest version?<br>
Also, to get j3 running recompile classpath with<br>
-fno-omit-frame-pointer (or take my patch from here:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/vmkit-commits/attachments/20100719/35754a6f/attachment.bin" target="_blank">http://lists.cs.uiuc.edu/pipermail/vmkit-commits/attachments/20100719/35754a6f/attachment.bin</a><br>
and apply it:<br>
$ cd classpath-0.97.2<br>
$ patch ./configure ./classpath_configure64.patch<br>
)<br>
<br>
That's now on j3<br>
<br>
Regards,<br>
<font color="#888888">Minas<br>
</font><div><br>
On Mon, Jul 19, 2010 at 9:20 PM, Joshua Warner <<a href="mailto:joshuawarner32@gmail.com" target="_blank">joshuawarner32@gmail.com</a>> wrote:<br>
> Forgot to send to the mailing list...<br>
><br>
> ---------- Forwarded message ----------<br>
> From: Joshua Warner <<a href="mailto:joshuawarner32@gmail.com" target="_blank">joshuawarner32@gmail.com</a>><br>
> Date: Mon, Jul 19, 2010 at 10:19 AM<br>
> Subject: Re: [LLVMdev] Building VMKit<br>
> To: nicolas geoffray <<a href="mailto:nicolas.geoffray@gmail.com" target="_blank">nicolas.geoffray@gmail.com</a>><br>
><br>
><br>
> Thanks Nicolas, that worked great!<br>
><br>
> Now, I'm having trouble invoking the compiler properly:<br>
> $ llcj Hello.class -o=Hello.ll<br>
> $ cat Hello.ll<br>
> cat: Hello.ll: No such file or directory<br>
> $ j3 Hello<br>
> j3: JavaClass.cpp:480: j3::JavaObject* j3::Class::doNew(j3::Jnjvm*):<br>
> Assertion `(this->isInitializing() ||<br>
> classLoader->getCompiler()->isStaticCompiling()) && "Uninitialized class<br>
> when allocating."' failed.<br>
> Aborted<br>
> $ java Hello<br>
> hello, world!<br>
><br>
> "Hello" is a completely banal "hello world!" program.<br>
><br>
> Joshua<br>
</div><div><div></div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div></div></div><br>
</blockquote></div></div></div><br>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br>