RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM]

[Roman Kennke]

Am Mittwoch, den 21.11.2012, 11:43 -0800 schrieb Christian Thalinger:
> On Nov 21, 2012, at 9:31 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> > Hi there,
> > 
> > during the last days I worked on fixing the Shark compiler for Hotspot
> > to get it to build and run again, with the latest Hotspot code and LLVM.
> > Here are some details:
> > 
> > - A lot of changes are just to make it build and the compiler happy. For
> > example, I had to remove a lot of 'const' qualifiers because of API
> > changes in LLVM.
> > - Most other changes have to do with the split of the oop and metadata
> > class hierarchies in Hotspot.
> > - Then there have been a few changes caused by LLVM changes and
> > improvements, most notably the LLVM intrinsics for atomic operations
> > (memory barrier and cmpxchg) have been removed and now have a
> > representation directly in LLVM's IR. This makes our code a little
> > nicer.
> > 
> > I tested this by running a number of applications, most notably Eclipse
> > (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a
> > bunch of other stuff.
> > 
> > I would like to get this integrated into OpenJDK now if possible. You
> > can find the full webrev here:
> > 
> > http://cr.openjdk.java.net/~rkennke/shark/webrev.00/
> 
> The changes seem to touch almost only shark files so these should be fine.  One question though:
> 
> +  develop(bool, SharkShowCompiledMethods, false,                              \
> 
> Isn't PrintCompilation doing that already?

Oh yes, didn't know that one! And it's even much better.

> The shared code changes look good.  I filed:
> 
> 8003868: fix shark for latest HotSpot and LLVM

Thanks. I removed the above flag, and posted another webrev:

http://cr.openjdk.java.net/~rkennke/shark/webrev.01/

Cheers,
Roman