<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hello again Gaël, et al -</div><div><br></div><div>I have returned to attempt modifications to "fix" VMKit to produce a working Java AOT! I would like to complete the modifications to VMKit AOT, and I would sincerely appreciate your help to keep me moving in the right direction.</div><div><br></div><div>From your email on- and off-list, I understand that you have successfully reproduced the error I reported, and you checked in a VMKit branch ("<a href="http://llvm.org/svn/llvm-project/vmkit/branches/aot">http://llvm.org/svn/llvm-project/vmkit/branches/aot</a>" ) with some additions and modifications -- thank you! I checked out your changes, but I have some questions. </div><div><br></div><div>1- Build / code changes</div><div>1A- Using examples/aot/Makefile to build target aot-test</div><div><div>The build rule in this Makefile for "%.class.o : %.class.bc" isn't used when building intermediate target vmkit_aot/examples/aot/Release+Asserts/HelloWorld.class.o, and so it doesn't get additional flags ("-load /path/to/vmkit_aot/Release+Asserts/lib/static-gc-printer.so -j3-aot"). The generic rule "%.o : %.bc" from the included ../../Makefile.rules is used. I don't exactly know why; I thought pattern rules favored shorter stem. I moved the rule to %.class.bc.o:%.class.bc to *before* the `include` to imply preference, and it works. Certainly there are other ways to solve this. The same is true for examples/aot/java/Makefile .</div></div><div><br></div><div>1B- With that hack, when linking aot-test, I get the same "multiple definition of" the following symbols:</div><div> __L__Vstatic_buf </div><div> __L__Vvirtual_buf</div><div> ____Vstatic_buf</div><div> ____Vvirtual_buf</div><div>because they are defined both in HelloWorld.class.o (in libHelloWorld.a) and in /path/to/vmkit_aot/Release+Asserts/lib/libPrecompiled.a . At first glance, the disassembly of both versions of __L__Vstatic_buf are equivalent. I experimented with stripping these symbols from one or both of the offending objects, such as adding this line to the recipe for HelloWorld.class.o</div><div> strip --strip-symbol=__L__Vstatic_buf --strip-symbol=__L__Vvirtual_buf --strip-symbol=____Vstatic_buf --strip-symbol=____Vvirtual_buf $@</div><div>The result of removing the symbols from either object is indistinguishable (to me).</div><div><br></div><div><div>Can you explain these to me: </div><div>I- Where do these symbols come from?</div><div>II- What do they do?</div><div>III- How should this conflict be resolved (e.g., which version to use)?</div><div><br></div></div><div>1C- With that hack, I can build vmkit_aot/Release+Asserts/bin/aot-test (default target of examples/aot/Makefile), but it fails with the same "Wrong stack trace" error as before:</div><div> aot-test: JavaRuntimeJIT.cpp:381: void *j3ResolveVirtualStub(j3::JavaObject *): Assertion `FI->Metadata != __null && "Wrong stack trace"' failed.</div><div>I assume this is "the last" error. :) I can step through in the debugger, but I don't understand what's wrong and/or what needs to be changed. </div><div><br></div><div><br></div><div>2- Documentation</div><div>In previous emails, you had said ... :</div><div>2A- you understand the problem with VMKit AOT. Can you describe your understanding of this problem and how to fix it? Any level of detail would be helpful.</div><div><br></div><div>2B- you added a TODO list, but I don't see it in the repository. Would you show me where it is? This TODO list would be very helpful for a VMKit hacker like me :)</div><div><br></div><div>2C- you were working on documentation of the VMKit design. I don't mean to pester you, but this would also be very helpful for me when learning how to make any necessary changes to VMKit.</div><div><br></div><div>Thank you again,</div><div>Brian</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><div>On Sep 10, 2014, at 2:24 PM, Brian Faull <<a href="mailto:bfaull@cog-e.com">bfaull@cog-e.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Okay -- thank you for the suggestions, but without my hack (which I will happily abandon! :) I'm still getting the error "Should have found a JavaMethod". I'll describe what I'm doing and attach the bitcode as you requested.</div><div><br></div><div>Here's what I'm doing, if you're able to recreate:</div><div>* installed OpenJDK 6u23</div><div>* clean version of VMKit from the repository, configured as follows:</div><div> ./configure --with-llvm-config-path=/path/to/llvm33/bin/llvm-config --with-classpath-impl=openjdk --with-openjdk-path=/path/to/jdk1.6.0_23</div><div>where directory /path/to/jdk1.6.0_23 contains the installation of OpenJDK6u23, e.g., bin, jre, lib, include.</div><div>* your class-to-bitcode commands, which includes several things I hadn't tried. Specifically, I'm invoking as follows:</div><div> vmjc -print-aot-stats HelloWorld.class</div><div> opt -load=../../Release+Asserts/lib/static-gc-pass.so -StaticGCPass -o HelloWorld.class.gc.bc HelloWorld.class.bc</div><div> llc -load=../../Release+Asserts/lib/static-gc-printer.so HelloWorld.class.gc.bc</div><div><br></div><div>The last command fails with the "Should have found a JavaMethod" error. The only difference from yours is the order of arguments to `opt`, just to strictly follow the `opt [options] <input bitcode file>` usage.</div><div><br></div><div>I think the `vmjc` command needs additionally the "-main=" argument, but I have tried both ways with the same outcome.</div><div><br></div><div>Further comments inline below, much snipping.</div><div><br></div><div><br></div><div>On Sep 9, 2014, at 7:42 PM, Gaël Thomas <<a href="mailto:gael.thomas00@gmail.com">gael.thomas00@gmail.com</a>> wrote:</div><div><blockquote type="cite"><p dir="ltr">Oups, sorry for the mistake, llcj (not llc:)) is not more maintained!</p><p dir="ltr">Gaël </p>
<div class="gmail_quote">Le 10 sept. 2014 00:27, "Gaël Thomas" <<a href="mailto:gael.thomas00@gmail.com">gael.thomas00@gmail.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">Hi Brian,<br>
<br></blockquote></div></blockquote>...<br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<br>
So, I answer in your previous mail. As it's the beginning of the year<br>
(I'm teaching), I haven't found any time to install vmkit and make the<br>
tests. But we will proceed step by step to understand the problem. In<br>
parallel, I'm also writing a documentation to describe the internals<br>
of VMKit, it will be useful for you and other people interested by the<br>
AOT.<br></blockquote></div></blockquote><div><br></div>Fantastic; such a document would be very helpful; thank you. And good luck with the teaching!</div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">You only have to use openjdk (gnu classpath is not more maintained as<br>
the project is also retired:)). We have a bug with the new versions of<br>
openjdk, and we are using the 6u23. I don't know if all the previous<br>
versions will be ok. So, I suggest using this version.<br></blockquote></div></blockquote><div><br></div><div><div>I found OpenJDK6u23 somewhat difficult to find; for others searching it's at </div><div><a href="http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html#jdk-6u23-oth-JPR">http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html#jdk-6u23-oth-JPR</a></div><div><br></div><div>I had previously not found a version this old at </div><div><a href="https://java.net/projects/openjdk6/downloads">https://java.net/projects/openjdk6/downloads</a></div></div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: relative; z-index: 0; ">
<br>
> => The output I see is as follows:<br>
> ==========<br>
> llc: VmkitGCPrinter.cpp:268: llvm::Constant *FindMetadata(const llvm::Function &): Assertion `0 && "Should have found a JavaMethod"' failed.</blockquote></div></blockquote>...<br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: relative; z-index: 0; ">> Are we on the right path? Is this a good start?<br>
<br>
It's a very good start :) But your hack is not the good solution<br>
because you should return from FindMetaData at the line 229 (you<br>
should not reach the test at line 239).<br></blockquote></div></blockquote><div><br></div><div>Good start! This seems to be the problem, because I seem to be in the wrong code path.</div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: relative; z-index: 0; "><br>
So, can you try this compilation scheme (without your hack in<br>
StaticGCPrinter.cpp:))?<br>
<br>
vmjc -print-aot-stats HelloWorld.class<br>
opt -load=../../Release+Asserts/lib/static-gc-pass.so -StaticGCPass<br>
HelloWorld.class.bc -o HelloWorld.class.gc.bc<br>
llc -load=../../Release+Asserts/lib/static-gc-printer.so HelloWorld.class.gc.bc<br></blockquote></div></blockquote><div><br></div><div><div>With the commands as you suggest, I step through the execution of the `llc` command in the debugger. When the HelloWorld::main() function is passed to FindMetadata(), the F.getName() is "JnJVM_HelloWorld_main___3Ljava_lang_String_2" and F.UseList is NULL (wrong, I think). This forces the code path to drop immediately out of the first for() loop (past the return at VmkitGCPrinter.cpp:229, and on to the block at :239). In contrast, when the <init> function (F.getName() is "JnJVM_HelloWorld__0003Cinit_0003E__") is processed in FindMetadata(), F.UseList is non-NULL.</div><div><br></div></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: relative; z-index: 0; ">
<br>
If it does not change anything, can you send me the<br>
HelloWorld.class.bc file? I will quickly see if everything is ok for<br>
the GC and where is the problem.<br></blockquote></div></blockquote><div><br></div><div>The bitcode is (effectively) identical before and after the `opt` line, which is presumably not correct. `llvm-diff` reports no differences, and a `diff` of the `llvm-dis` output reports only that the module names are different. I will attach the file off-list because I expect it will get scrubbed anyway.</div><div><br></div><div>The above is with your exact commands. Adding the "-main=HelloWorld" argument to `vmjc` puts 3 additional symbols in the bitcode:</div><div><div> U StartJnjvmWithoutJIT</div><div> T main</div><div> d mainClass</div><div>That is, adds a main() in addition to the HelloWorld::main() (which gets mangled as "JnJVM_HelloWorld_main___3Ljava_lang_String_2"). I think this is necessary and correct for non-JIT linking and execution, but that's perhaps further down the line.</div></div><div><br></div><div>I am continuing to look at the situation, but I would appreciate hearing anything that you can see from the bitcode file.</div><div><br></div><div>Thank you again!</div><div>Brian</div><div><br></div><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: relative; z-index: 0; "><br>
<br>
2014-09-09 21:51 GMT+02:00 Brian Faull <<a href="mailto:bfaull@cog-e.com">bfaull@cog-e.com</a>>:<br>
> Hello again Gaël, (et al)<br>
><br>
> More on rekindling work on VMKit! Thank you for your interactions thus far on- and off-list.<br>
><br>
> As you suggested in your VMKit-retirement email (to which I'm attempting to respond), I'm interested in producing a Java-to-LLVM compiler out of VMKit. I'd like to take you up on your offer to help understand the architecture. If I can get the a Java-to-LLVM compiler working for my purposes, I'll be happy to maintain at least this part of the VMKit project.<br>
><br>
> To that end, I have exactly one fundamental question to start:<br>
><br>
><br>
> How do you suggest to perform Java-to-LLVM compilation using VMKit?<br>
><br>
><br>
> Here are my thoughts on this:<br>
><br>
> It looks like the `llcj` tool (VMKit/tools/llcj/llcj.cpp) was meant for this; it declares itself as "Java to native compiler" but it appears that it hasn't been maintained (e.g., deprecated interfaces, no-longer-existent command-line options and libraries). `llcj` is described in Appendix A of Geoffray's thesis, <a href="http://pagesperso-systeme.lip6.fr/Nicolas.Geoffray/these-geoffray.pdf" target="_blank">http://pagesperso-systeme.lip6.fr/Nicolas.Geoffray/these-geoffray.pdf</a> linked from the VMKit site.<br>
><br>
> `llcj` attempts the following to translate Java to native:<br>
> * vmjc (Java .class => LLVM bitcode .bc)<br>
> * opt (LLVM bitcode optimizer)<br>
> * llc (LLVM bitcode => target assembly .s)<br>
> * gcc (assemble and link)<br>
><br>
> Is that "The Right Way"?<br>
><br>
> After some time hacking various changes, I can use basically that method to compile VMKit/tools/trainer/HelloWorld.java into a linked executable (but it barfs at runtime and I can't fix it).<br>
><br>
> I'm doing roughly the following, on x86_64, using LLVM3.3, OpenJDK 1.6.0 build 30, a debug build of VMKit (required small build-hacks, which I could describe on request), and the (perhaps-incorrect) edit to `static-gc-printer.so` described in an earlier post: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076128.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076128.html</a> :<br>
> cd /path/to/vmkit/tools/trainer<br>
> javac HelloWorld.java<br>
> ../../Debug+Asserts/bin/vmjc -main=HelloWorld -print-aot-stats HelloWorld.class<br>
> /path/to/llvm33/bin/llc -load=../../Debug+Asserts/lib/static-gc-printer.so HelloWorld.class.bc<br>
><br>
> That produces for me a reasonable native assembly file.<br>
><br>
> Next I assemble and link, using a set of libraries/objects inspired by `llcj` and refined by a semi-automated trial-and-error:<br>
> /path/to/llvm33/bin/clang++ -g3 -O0 -o HelloWorld.class.exe HelloWorld.class.sed.s -L/path/to/vmkit_test-codechanges/Debug+Asserts/lib -L/path/to/llvm33/lib -pthread -lm -ldl -lz -lJ3 -lClasspath -lJ3Compiler -lCommonThread -lVmkit -lVmkitCompiler -lPrecompiled -lFinalMMTk -lLLVMX86Info -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Utils -lLLVMX86AsmPrinter -lLLVMExecutionEngine -lLLVMScalarOpts -lLLVMipo -lLLVMipa -lLLVMAnalysis -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTarget -lLLVMJIT -lLLVMRuntimeDyld -lLLVMObject -lLLVMObjCARCOpts -lLLVMVectorize -lLLVMTransformUtils -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMMC -lLLVMCore -lLLVMSupport -rdynamic<br>
><br>
> This links and executes, but here are my problems/hacks:<br>
> * `llc` generates an assembly file with symbols (e.g., ____Vstatic_buf() and friends) that conflict with one of the archives listed above (libPrecompiled.a, which I believe is necessary for java_lang_Object and others). I basically remove those symbols (sed '/_buf$/ s/globl/weak/' HelloWorld.class.s > HelloWorld.class.sed.s) before assembling. I don't know if this is a reasonable hack or if it's causing problems.<br>
> * I get the following error at runtime (because some fields are NULL) and I can't make progress:<br>
> HelloWorld.class.exe: JavaRuntimeJIT.cpp:381: void *j3ResolveVirtualStub(j3::JavaObject *): Assertion `FI->Metadata != __null && "Wrong stack trace"' failed.<br>
><br>
> Am I on the right path, or should I be considering other methods? Or wrong entirely?<br>
><br>
> Ultimately, I propose changing `llcj` into something like a Python script that executes the appropriate utilities to start from Java source and resulting in a linked target-architecture executable, using `clang++` as compiler-driver for assembling and linking. It would be essentially a work-alike to `gcj`.<br>
><br>
> Can you help point me in the right direction?<br>
><br>
> Thank you,<br>
> Brian<br>
><br>
><br>
><br>
><br>
><br>
> Date: Mon, 1 Sep 2014 21:34:58 +0200<br>
> From: Gaël Thomas <<a href="mailto:gael.thomas00@gmail.com">gael.thomas00@gmail.com</a>><br>
> To: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>>, Nicolas<br>
> Geoffray <<a href="mailto:nicolas.geoffray@gmail.com">nicolas.geoffray@gmail.com</a>><br>
> Subject: [LLVMdev] VMKit is retired (but you can help if you want!)<br>
> Message-ID:<br>
> <CAOWuPDcZBpt_JJ5yo5YN=C+RWbtbneXB1UGd90d0mXdnrs8=<a href="mailto:RQ@mail.gmail.com">RQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> Hi all,<br>
><br>
> So, as explained in the LLVM weekly, the VMKit project is retired. It<br>
> was a very fun project, but we don't have any manpower to maintain the<br>
> code since one year. If someone is interested by restarting the<br>
> project, just send me an email, I can help to understand the<br>
> architecture of the project and how it works. I'm pretty sure that we<br>
> can also extract a Java to LLVM compiler easily (I know that some<br>
> people are interested by that).<br>
><br>
> And I want to thank all the LLVM team for their support during these<br>
> last ten (yes ten:)) years! Without their help, it would have been<br>
> impossible to develop VMKit.<br>
><br>
> See you and thank you!<br>
> Gaël<br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
--<br>
-------------------------------------------------------------------<br>
Gaël Thomas, Associate Professor, UPMC<br>
<a href="http://pagesperso-systeme.lip6.fr/Gael.Thomas/" target="_blank">http://pagesperso-systeme.lip6.fr/Gael.Thomas/</a><br>
-------------------------------------------------------------------<br>
</blockquote></div>
</blockquote></div><br></div></blockquote></div><br></body></html>