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
