RFE: configuration for compiling HotSpot with Clang

[Volker Simonis]

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 --------------
A non-text attachment was scrubbed...
Name: clang.patch
Type: text/x-patch
Size: 20085 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110211/d0467981/attachment-0001.bin