RFE: configuration for compiling HotSpot with Clang

Coleen Phillimore coleen.phillimore at oracle.com
Tue Feb 15 08:47:18 PST 2011


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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110215/9bcb6069/attachment-0001.html 

More information about the hotspot-dev mailing list