[PATCH] Fix Shark build in JDK9

[Roman Kennke]

Hi David,


> > - In ciTypeFlow.cpp only include some files and code only when building
> > C2. I don't think that code makes sense outside of C2. (That's the issue
> > that you've seen).
> 
> Looks okay but someone from compiler team needs to comment. There may be 
> other code that need adjusting.

It might be less intrusive to guard this with #ifndef SHARK instead of
#ifdef COMPILER2. I don't think it makes a difference though.

> > - In allocation.hpp, exclude the operator overrides for new etc, LLVM
> > does allocations itself, and this would blow up.
> 
> I'm intrigued as the allocation strategy is not tied to the compiler but 
> pervasive to the whole VM runtime.

In a comment it says this whole block is disabled in PRODUCT versions,
because of 3rd party code that might be in use. This is basically the
situation with Shark: we need to be able to do allocations in LLVM, and
LLVM doesn't know about Hotspot's allocation safeguards. That's why I
disable it for Shark builds.

> > - In handles.hpp and handles.inline.hpp, I added an argument
> > check_in_stack so that I can disable the in-stack check for the
> > SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and the
> > methodHandle inside the SharkNativeWrapper. I could have excluded that
> > check altogther using an #ifndef SHARK, but the way I implemented it
> > seemed more finegrained.
> 
> I'd prefer an ifndef SHARK rather than change the API.

Yeah ok, I understand that. However, I do not know how I can do an
#ifdef inside a #define block. I'd need to duplicate the whole block,
and put #ifdefs around those. This raises the question about code
maintainability though, any changes in one block need to be done in the
other block as well. I can do that if you prefer over the API change.
That being said, multi-line-#defines are evil anyway ;-)

Roman