[PATCH] Fix Shark build in JDK9

[David Holmes]

Hi Roman,

On 14/01/2015 7:41 AM, Roman Kennke wrote:
> Ok I think I found a way to avoid copying the whole #define block just
> for one line. I define that line before (and empty in case of SHARK) and
> use that inside the big #define.
>
> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.02/

Can you use SHARK_ONLY or NOT_SHARK macros? I think that would be cleaner.

Still need a second hotspot reviewer - preferably someone from compiler 
team.

And was a bug filed for this?

Thanks,
David

> Please review and push if ok.
>
> Roman
>
> Am Freitag, den 09.01.2015 um 15:27 +1000 schrieb David Holmes:
>> Hi Roman,
>>
>> Commenting on the hotspot changes ...
>>
>> On 8/01/2015 9:01 PM, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>> I'm CC-ing hotspot-dev for review of Hotspot code related changes.
>>>
>>> Yes, some additional changes to Hotspot are required. This is the full
>>> set of changes needed to build and run Shark:
>>>
>>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/
>>>
>>> In detail:
>>>
>>> - In the Makefile fix a typo to be able to build unzipped debuginfo.
>>
>> Ok.
>>
>>> - 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.
>>
>>> - In systemDictionary.cpp, exclude some code for Shark that creates and
>>> checks native wrappers for method handle intrinsics. Invokedynamic stuff
>>> is not yet implemented in Shark, so we can't do this.
>>
>> Ok.
>>
>>> - 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 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.
>>
>> Thanks,
>> David
>>
>>> - In SharkCompiler, I pulled out the code to initialize LLVM into its
>>> own method, and the call to set_state(initialized) out of the
>>> execution-engine-lock. This would otherwise complain about wrong
>>> lock-ordering.
>>> - In SharkRuntime, I changed the cast from intptr_t to oop to work with
>>> the new picky compilers ;-)
>>>
>>> Please review.
>>>
>>> Thanks and best regards,
>>> Roman
>>>
>>> Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
>>>> Hello Roman,
>>>>
>>>> This addition looks good to me.
>>>>
>>>> Thinking about what the others said, it might be inconvenient to have
>>>> all this be pushed to different forests. I tried applying all the
>>>> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
>>>> have more hotspot changes to be able to finish the build?
>>>>
>>>> My failure is:
>>>>
>>>>     ciTypeFlow.o
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
>>>> In file included from
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>>>>                     from
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>>>>                     from
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
>>>> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
>>>>
>>>>    From what I can see, adfiles are not generated for zero or zeroshark
>>>> builds, so the include should probably be removed.
>>>>
>>>> Would you still like me to push what you currently have to hs-rt?
>>>>
>>>> /Erik
>>>>
>>>> On 2015-01-07 21:21, Roman Kennke wrote:
>>>>> Hi Erik,
>>>>>
>>>>> When I built Zero and Shark on my Raspberry Pi, I noticed another
>>>>> problem when copying jvm.cfg into the right places. I fixed it in a
>>>>> similar way as I did for the SA stuff:
>>>>>
>>>>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
>>>>>
>>>>> I think that should be all for now.
>>>>>
>>>>> Please push that into JDK9 if you think that's fine.
>>>>>
>>>>> Best regards,
>>>>> Roman
>>>>>
>>>>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
>>>>>> On 2015-01-07 17:29, Roman Kennke wrote:
>>>>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>>>>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
>>>>>>>>> Hi Erik,
>>>>>>>>>
>>>>>>>>> Do you have a bug for this?
>>>>>>>>> No.
>>>>>>>>>
>>>>>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
>>>>>>>>> meantime for me to create my own bugs? Otherwise, please file one for
>>>>>>>>> me :-)
>>>>>>>> You should be able to log in to https://bugs.openjdk.java.net and create
>>>>>>>> bugs since you have an OpenJDK identity.
>>>>>>> Done:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
>>>>>>>
>>>>>>> While I'm at it, is it possible for me to push my own changes (except
>>>>>>> hotspot of course)? If yes, what needs to be done for regenerating the
>>>>>>> configure files? Simply run autogen.sh in common/autoconf with whatever
>>>>>>> version of autotools I have? Or doesn't it make sense at all b/c you
>>>>>>> need to regenerate your closed scripts?
>>>>>> It requires you to run common/autogen.sh yes, and that will require you
>>>>>> to have autoconf 2.69 installed. But since we also need to regenerate
>>>>>> the closed version, I can take care of the push for you. Will do it
>>>>>> tomorrow if that's ok?
>>>>>>
>>>>>> /Erik
>>>>>>> Roman
>>>>>>>
>>>>>
>>>>
>>>
>>>
>
>