search for: jcvm

...ng quite a bit. It is missing too much to support > programs that use System.Out, for example. Alkis is definitely the > person to talk to if you're interested in it. Thanks.. I'm actually more interested in what would be involved to hook up LLVM to an existing JVM. In particular JCVM (http://jcvm.sf.net). JCVM analyzes bytecode using Soot, emits C code, compiles that with GCC, and then loads executable code from the resulting ELF files.. given this design, using LLVM/modules instead of Soot/GCC/ELF would not be very much different, but would allow more cool things to happen. T...

On Sun, 23 Apr 2006, Reid Spencer wrote: >> Has it been hooked up to a JVM? If so, how and which ones? > > 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 the Java

...> used for class initialization as well. If that were the implementation then yes that could work. But using a null pointer like this probably wouldn't be the case. In Java you have to load a class before you initialize it, so the pointer to the type structure will already be non-null. In JCVM for example, there is a bit in type->flags that determines whether the class is initialized or not. This bit has to be checked before every static method invocation or static field access. You could reserve an entire byte instead of a bit, but I don't know if that would make it any easier to...

...issing too much to >> support programs that use System.Out, for example. Alkis is >> definitely the person to talk to if you're interested in it. > > Thanks.. I'm actually more interested in what would be involved to > hook up LLVM to an existing JVM. In particular JCVM (http:// > jcvm.sf.net). > JCVM analyzes bytecode using Soot, emits C code, compiles that with > GCC, > and then loads executable code from the resulting ELF files.. given > this > design, using LLVM/modules instead of Soot/GCC/ELF would not be > very much > different...

On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: > Chris Lattner wrote: > > On Mon, 24 Apr 2006, Archie Cobbs wrote: > >> Related idea.. what if all instructions (not just "invoke") could be > >> allowed to have an optional "except label ..."? > > > > This is the direction that we plan to go, when someone is interested >

...initialize it, so the pointer to the type > structure will already be non-null. That is why I said if you want it to be fast :-). My point was that if you want this to be fast you need to find a way to make it trap when a class is not initialized. If you employ the method you mention below for JCVM then you need to perform optimizations to simplify the conditionals. > In JCVM for example, there is a bit in type->flags that determines > whether the class is initialized or not. This bit has to be checked > before every static method invocation or static field access. You could >...

>>>>> "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 bit, but I don...

...r to the type >> structure will already be non-null. > > That is why I said if you want it to be fast :-). My point was that if > you want this to be fast you need to find a way to make it trap when a > class is not initialized. If you employ the method you mention below > for JCVM then you need to perform optimizations to simplify the > conditionals. I get it. My point however is larger than just this one example. You can't say "just use a null pointer" for every possible optimization based on front end information. Maybe that happens to work for active cla...

Tom Tromey wrote: >>>>>> "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...

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: >> In the JIT, devirtualization looks doable, though somewhat fiddly. At >> least, that is true for straightforward things like calls to methods >> in final classes, or calls to methods on objects allocated with 'new' >> in the current function. (The latter could be