Native wrapper compilation and LLVM 2.6

[Michael Franz]

What is the benefit of the native methods being handled differently?  From
your blog, you said the interpreted methods are put on a queue to be
compiled, the native methods are compiled immediately.  Couldn't the native
methods also be put on the same queue?

I am not suggesting that LLVM < 2.6 be kept, I am just curious why the logic
is different.

On Wed, Oct 28, 2009 at 5:58 AM, Gary Benson <gbenson at redhat.com> 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?
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20091028/1c3ff60a/attachment.html