similar to: [LLVMdev] LLVM-based JVM JIT for libgcj

hi Tom, I am really glad that someone has found time to step into that :-). Tom Tromey wrote: > I recently wrote an LLVM-based JIT plugin for libgcj and I thought > it'd be worthwhile to mention it here. > > It is in cvs on sourceforge, but afaics anonymous cvs there is pretty > broken at the moment... so if you want a copy, ask and I will email it > to you. wow. that is

On Tue, 18 Apr 2006, Tom Tromey wrote: > I recently wrote an LLVM-based JIT plugin for libgcj and I thought > it'd be worthwhile to mention it here. Cool! > Exception handling definitely does not work, I didn't even try to > implement it yet. I've been thinking about having some kind of simple > bridge between the LLVM and GCC worlds here -- very inefficient, but >

>>>>> "Jakob" == Jakob Praher <jp at hapra.at> writes: Jakob> I would definitely like to look into it. I'll send it in private email. Jakob> Yes very much! How did you find writing it directly in Jakob> SSA-form. Actually I used what Chris called "the alloca trick"... the JIT doesn't really generate SSA form but instead uses alloca to

>>>>> "Chris" == Chris Lattner <sabre at nondot.org> writes: >> FWIW I actually did this work twice, once for libjit and once for >> LLVM. I'm happy to provide a comparison, from a jit-writing >> perspective, if you're interested. Chris> Given your experience with both, I'd be very interested in any Chris> thoughts you have on

On Tue, 18 Apr 2006, Tom Tromey wrote: >>>>>> "Chris" == Chris Lattner <sabre at nondot.org> writes: >>> FWIW I actually did this work twice, once for libjit and once for >>> LLVM. I'm happy to provide a comparison, from a jit-writing >>> perspective, if you're interested. > > Chris> Given your experience with both,

>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: Vikram> Ok, this makes sense. But I was actually asking how you deal with Vikram> this in the LLVM JIT for libgcj (I guess it is too early for you to Vikram> have an answer). Yeah. I completely punted on exception handling in general, since at the moment there is really no hope for integrating

Chris> Are you using a debug or a release build? A release build (built with Chris> make ENABLE_OPTIMIZED=1) is often 10x to 20x smaller than a debug Chris> build, and links correspondingly faster. On some machines, a release Chris> build builds *faster* than a debug build because the debug symbols are Chris> so huge. The only thing you lose with a release build is the ability

On Apr 26, 2006, at 10:45 AM, Tom Tromey wrote: >>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: > > Vikram> Either way, one issue that you will have to deal with is > preserving > Vikram> the behavior of Java exceptions (assuming you care about > that). LLVM > Vikram> does not preserve the order of potentially

>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: Vikram> Either way, one issue that you will have to deal with is preserving Vikram> the behavior of Java exceptions (assuming you care about that). LLVM Vikram> does not preserve the order of potentially excepting instructions Vikram> (e.g., a divide or a load). This would have to be handled

Hi Tom, > I didn't dig into the Makefiles... are the libraries and whatnot built > -fPIC? If you do `make Verb=' then you'll see all the actual command invocations and can grep for bits of interest. Cheers, Ralph.

On Apr 26, 2006, at 3:06 PM, Tom Tromey wrote: > So until this is fixed the JIT for libgcj is more or less an > experimental toy. Ok, I understand, though it is unfortunate. I don't have any great insights into fixing this. > I'm going to keep developing it as an add-on for libgcj. > Hopefully I'll be able to distribute it in FC6 or FC7. > > Last night I found a

On Apr 23, 2006, at 9:32 PM, Archie Cobbs wrote: > Chris Lattner wrote: >>> I think the point of llvm-java was to avoid a JVM. That is, it >>> converts >> llvm-java is the JVM. >>> either Java source or Java bytecode into equivalent LLVM bytecode. I >> llvm-java only supports input from Java bytecode. >>> think the big thing lacking so far are

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Archie> Which bytecode will you recompile? In particular I'm thinking Archie> about active use checks: as you know the checks for class A have to Archie> be implemented in every other class B, C, D, ... that references a Archie> static field or method of A. Presumably you won't

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Archie> In JCVM for example, there is a bit in type->flags that Archie> determines whether the class is initialized or not. This bit Archie> has to be checked before every static method invocation or Archie> static field access. You could reserve an entire byte instead Archie> of a

Hi. I have more questions regarding llvm and using it as a jit for our purposes. Also, let me confess that I haven't actually used llvm yet (I'm still prototyping using gnu's libjit). Some of the issues that have come up from that work so far leads to me these questions: 1) We intend to use llvm as a jit in our expression compiler at compile-time only. At runtime, the x86 code

Hi Reid. Thanks for your response. We will be running this code in different processes across different nodes. Basically we have thousands of "executor" processes that are solely responsible for executing this code generated at compile-time across partitioned data. Rather than each one of these processes invoking the jit and compiling with full opts and all of that, we believe it may

On Tue, Mar 23, 2010 at 4:44 PM, Shasank Chavan <shanko_chavano at hotmail.com> wrote: > Hi.  I have more questions regarding llvm and using it as a jit for our > purposes.  Also, let me confess that I haven't actually used llvm yet (I'm > still prototyping using gnu's libjit).  Some of the issues that have come up > from that work so far leads to me these questions:

If you really trying to avoid linking everything into a shared library (easiest choice), consider splitting up the compilation into a few more steps: 1) Compile and optimize once as part of your build, target LLVM bitcode instead of machine code 2) Ship .bc files out to each node 3) Fix-up call instructions in a BasicBlockPass, run JIT without any/many additional IR optimizations enabled This

Greetings, I am searching for an alternative to sun's java implementation - one that is not under gpl.. I've been reading the vmkit code for JNI.. And I notice that it is not completely filled out yet... That's fine though, I see there is filled in function like most of the non implemented functions.. Couple of questions: Is the entire llvm required for java/cli vmkit to run?

If you distribute the .bc to a new machine and JIT it there, you wouldn't need to apply any relocations to call instructions, since the JIT will get all the offsets right when it does code generation on the node. I would strongly recommend the shared library approach over this one, because JIT compile time is dominated by code generation, not optimization. If you distribute the .bcs, then