RFE: configuration for compiling HotSpot with Clang

[Volker Simonis]

There was a longer discussion around the fix for the CHECK macros
about one and a half years ago. I started a patch that time but than
somehow forgot about it. Now with the new compiler (and the old
warnings) I remembered about it. I hope to get it done this time and
to send it out for review soon. Thank you for the offer to take care
about it.

Volker

On Tue, Feb 15, 2011 at 5:47 PM, Coleen Phillimore
<coleen.phillimore at oracle.com> wrote:
>
> Volker,
>
> The patch that you attached doesn't seem to fix any CHECK macros in return
> statements (bug 6889002).
> If you have a patch for this bug, I'll check it in for you.
>
> Coleen
>
>
> On 2/11/2011 1:24 PM, Volker Simonis wrote:
>
> Hi,
>
> at the FOSEDM I've heard Chris Lattner's very nice "LLVM and Clang"
> keynote. The claims he made in his talk have been very impressing: he
> was speaking about Clang being a "production quality" "drop-in
> replacement" for GCC with superior code generation and improved
> compile speed. Already during the talk I decided that I would be
> interesting to prove his pretensions on the HotSpot VM. If you're
> interested in the details you can read my blog:
>
> http://weblogs.java.net/blog/simonis/archive/2011/02/10/compiling-hotspot-vm-clang
>
> For the impatient the summary is that Clang is still slower than
> current GCC versions and the generated code seems to be slightly
> slower as well. Nevertheless, Clang has excellent warning capabilities
> and is an excellent C++ compiler with regard to C++ conformance. (Now
> it's probably a good time to finally fix
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6889002  which I've
> promised already more than a year ago at
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-October/thread.html#2175
> :)
>
> Attached you can find a patch which contains a Clang configuration for
> the HotSpot build (Linux x86/x86_64). A Clang make can be triggered by
> passing "USE_CLANG=true" to the make command. Warnings are currently
> turned off for the reasons mentioned above.
>
> This patch may also be interesting in the context of the new MacOs X
> port, where Clang is much more common (or perhaps even the default C++
> compiler - i don't know?).
>
> Notice that this patch contains one additional change compared to the
> patch in the blog. While I did the tests for the blog with an slightly
> outdated HS20b03 I synced a brand new version today to prepare the
> patch. With this new version I found a true C++ bug in
> "src/share/vm/utilities/hashtable.hpp" which was introduced recently
> by the "6990754: Use native memory and reference counting to implement
> SymbolTable" change and which has to do with name lookup of
> nondependent names in dependent base classes (see
> http://www.parashift.com/c++-faq-lite/templates.html#faq-35.19 for a
> nice explanation). Wouldn't have happened with Clang:)
>
> Regards,
> Volker
>
>