Native wrapper compilation and LLVM 2.6

[Matthias Klose]

On 28.10.2009 10:58, Gary Benson wrote:
> Hi all,
>
> This past week or so I've been working on making Shark support
> compilation of native (JNI) method wrappers.  The way HotSpot
> does this has the wrappers being generated outside the compiler
> thread, so you have LLVM calls being made from two different
> threads.
>
> LLVM<  2.6 doesn't support this, and it's not possible to work
> around this with locking; the compiler thread in HotSpot runs
> _thread_in_native, which means it cannot hold locks.  (And if
> you hack one in there, it deadlocks at the first safepoint ;))
>
> I'm wondering... is anyone using Shark with LLVM<  2.6?  I have
> two options here:
>
>   - Write it such that JNI compilation is conditional on
>     LLVM>= 2.6.  This requires lots of #ifdefs but is possible.
>
>   - Strip out LLVM<  2.6 support.  This is easier (and neater,
>     IMO).  But not really an option if someone depends on it.
>
> What do people think?

I updated llvm to snapshot builds over the last months and updated to the final 
llvm-release for tomorrow's Ubuntu release. Unfortunately this did break openctl 
(not working with 2.6 yet). the 2.6 upstream release doesn't work without 
patches on arm, Xerces already did provide one patch. Not sure about other 
archs, at least shark fails to build eclipse on at least ix86 and powerpc. So 
maybe it's time to include llvm as an optional build item into IcedTea, and 
provide patches/snapshots on IcedTea, as is done for unrelated things like 
visualvm as well.

   Matthias