[PATCH] Fix Shark build in JDK9

Wed Jan 14 08:35:17 UTC 2015

On 2015-01-14 08:22, David Holmes wrote:
> 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?
>
A bug was filed at least: https://bugs.openjdk.java.net/browse/JDK-8068598

I promised to handle the push when it's all reviewed.

/Erik

> 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
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>