Native wrapper compilation and LLVM 2.6

[Gary Benson]

Matthias Klose wrote:
> On 28.10.2009 10:58, Gary Benson wrote:
> > 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.

So are you shipping with 2.6 now, or are you still using 2.5 for
some/all releases?

> 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.

I thought anything less than 2.6 didn't work on ARM anyway.  Xerxes?

> Not sure about other archs, at least shark fails to build eclipse on
> at least ix86 and powerpc.

Ugh.  Did they work with 2.5?

> 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.

Could do.  Would you be interested in maintaining this?

Cheers,
Gary

-- 
http://gbenson.net/