[LLVMdev] Fwd: Building VMKit
Joshua Warner
joshuawarner32 at gmail.com
Tue Jul 20 11:59:25 PDT 2010
Hi Nicolas,
I had a discussion with the lead developer behind Avian, and we decided that
for the sake of simplicity, we would use a custom-written translator based
on the Java ASM library to do the class-to-llvm translation.
Perhaps in the future we could reconsider using VMKit - but for now, it
seems just a bit too involved.
Thanks for all your help!
Regards,
Joshua
On Tue, Jul 20, 2010 at 11:46 AM, nicolas geoffray <
nicolas.geoffray at gmail.com> wrote:
> On Tue, Jul 20, 2010 at 6:36 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote:
>
>> 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.
>>>
>>
>> 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.
>>
>
> 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.
>
>
>>
>> What about something like a --emit-unlowered-llvm option on llcj that just
>> spits out the LLVM IR before running this lowering pass?
>>
>
> 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.
>
>
>>
>>> 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.
>>>
>>
>> Could this be another case for emitting calls in the IR that are lowered
>> by a later pass?
>>
>
> 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?
>
>
>> Avian only needs a 1-word header - it uses the lower bits of the vtable
>> pointer for GC and hashing.
>>
>
> Cool. And on a synchronized, it pushes the header on the stack? Or Avian is
> not multi-threaded?
>
>
>>
>>
>>>
>>> * 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.
>>>>
>>>
>>> VMKit already does that, thanks to LLVM code generators.
>>>
>>
>> I was more concerned with whether this is what the llcj driver does.
>>
>
> Yes, llcj can generate assembly files, dynamic libraries, object files,
> executables, etc.
>
>
>> 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.
>>
>
> 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.
>
> 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.
>>
>
> 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.
>
> 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?
>>
>>
> It will definitely improve VMKit. It may end up only being used with Avian,
> but at least it opens more opportunities.
>
>
>> 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.
>>
>>
> 64-bit linux is near to being fully supported. There is little code in
> VMKit (except the GC) that is arch-dependent.
>
>
>> 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).
>>
>
> Using the vmjc tool in VMKit and LLVM lowering passes seems like a nice
> option to me.
>
> Nicolas
>
>
>> Joshua
>>
>>
>>>
>>> Joshua
>>>>
>>>>
>>>> On Tue, Jul 20, 2010 at 9:07 AM, nicolas geoffray <
>>>> nicolas.geoffray at gmail.com> wrote:
>>>>
>>>>> Hi Joshua,
>>>>>
>>>>> What plans did you have for GC? No GC at all or Avian JVM has its own
>>>>> GC (and is it precise or not?)?
>>>>>
>>>>> 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?
>>>>>
>>>>> Also, note that platform support will be strongly dependent on LLVM
>>>>> support.
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>> On Tue, Jul 20, 2010 at 4:41 PM, Joshua Warner <
>>>>> joshuawarner32 at gmail.com> wrote:
>>>>>
>>>>>> Hi Nicolas,
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Regards,
>>>>>> Joshua
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 20, 2010 at 8:00 AM, nicolas geoffray <
>>>>>> nicolas.geoffray at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Joshua,
>>>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 20, 2010 at 3:56 PM, Joshua Warner <
>>>>>>> joshuawarner32 at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Minas,
>>>>>>>>
>>>>>>>> I tried recompiling Classpath with -fno-omit-frame-pointer, and now,
>>>>>>>> instead of printing an error message, j3 just segfaults in
>>>>>>>> "j3::JnjvmClassLoader::loadClassFromAsciiz(char const*, bool, bool)
>>>>>>>> ()"
>>>>>>>>
>>>>>>>> I ran llcj under strace and found that it is not even opening the
>>>>>>>> input or output files, but is otherwise running normally.
>>>>>>>>
>>>>>>>> Updating to the latest SVN version (revision 108831) didn't change
>>>>>>>> anything (I was only a few days out of date).
>>>>>>>>
>>>>>>>> I'm not sure where to go from here. Does this fit with any of the
>>>>>>>> known problems under 64-bit linux?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joshua
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 19, 2010 at 4:45 PM, Minas Abrahamyan <
>>>>>>>> minas.subs at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Joshua,
>>>>>>>>> > $ j3 Hello
>>>>>>>>> > j3: JavaClass.cpp:480: j3::JavaObject*
>>>>>>>>> j3::Class::doNew(j3::Jnjvm*):
>>>>>>>>> > Assertion `(this->isInitializing() ||
>>>>>>>>> > classLoader->getCompiler()->isStaticCompiling()) &&
>>>>>>>>> "Uninitialized class
>>>>>>>>> > when allocating."' failed.
>>>>>>>>> > Aborted
>>>>>>>>>
>>>>>>>>> Regarding to j3 in 64 bit version, it should work now after we've
>>>>>>>>> found crush reason,
>>>>>>>>> both in Debug and in Release versions. (and its 32 bit version was
>>>>>>>>> continuously working)
>>>>>>>>>
>>>>>>>>> But your case is something strange, crush didn't type such
>>>>>>>>> messages.
>>>>>>>>> Have you taken VMkit from svn and latest version?
>>>>>>>>> Also, to get j3 running recompile classpath with
>>>>>>>>> -fno-omit-frame-pointer (or take my patch from here:
>>>>>>>>>
>>>>>>>>> http://lists.cs.uiuc.edu/pipermail/vmkit-commits/attachments/20100719/35754a6f/attachment.bin
>>>>>>>>> and apply it:
>>>>>>>>> $ cd classpath-0.97.2
>>>>>>>>> $ patch ./configure ./classpath_configure64.patch
>>>>>>>>> )
>>>>>>>>>
>>>>>>>>> That's now on j3
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Minas
>>>>>>>>>
>>>>>>>>> On Mon, Jul 19, 2010 at 9:20 PM, Joshua Warner <
>>>>>>>>> joshuawarner32 at gmail.com> wrote:
>>>>>>>>> > Forgot to send to the mailing list...
>>>>>>>>> >
>>>>>>>>> > ---------- Forwarded message ----------
>>>>>>>>> > From: Joshua Warner <joshuawarner32 at gmail.com>
>>>>>>>>> > Date: Mon, Jul 19, 2010 at 10:19 AM
>>>>>>>>> > Subject: Re: [LLVMdev] Building VMKit
>>>>>>>>> > To: nicolas geoffray <nicolas.geoffray at gmail.com>
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Thanks Nicolas, that worked great!
>>>>>>>>> >
>>>>>>>>> > Now, I'm having trouble invoking the compiler properly:
>>>>>>>>> > $ llcj Hello.class -o=Hello.ll
>>>>>>>>> > $ cat Hello.ll
>>>>>>>>> > cat: Hello.ll: No such file or directory
>>>>>>>>> > $ j3 Hello
>>>>>>>>> > j3: JavaClass.cpp:480: j3::JavaObject*
>>>>>>>>> j3::Class::doNew(j3::Jnjvm*):
>>>>>>>>> > Assertion `(this->isInitializing() ||
>>>>>>>>> > classLoader->getCompiler()->isStaticCompiling()) &&
>>>>>>>>> "Uninitialized class
>>>>>>>>> > when allocating."' failed.
>>>>>>>>> > Aborted
>>>>>>>>> > $ java Hello
>>>>>>>>> > hello, world!
>>>>>>>>> >
>>>>>>>>> > "Hello" is a completely banal "hello world!" program.
>>>>>>>>> >
>>>>>>>>> > Joshua
>>>>>>>>> _______________________________________________
>>>>>>>>> LLVM Developers mailing list
>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> LLVM Developers mailing list
>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100720/ec5792b6/attachment.html>
More information about the llvm-dev
mailing list