[PATCH] Fix Shark build in JDK9

Thu Jan 8 11:38:54 UTC 2015

Hello Roman,

Thanks for the full patch!

I discovered a problem with the top repo patch. When autoconf (using m4) 
evaluates your change, the brackets disappear. To fix this, more 
brackets need to be added. Here is a version that works for me that will 
make the correct sed expression appear in the generated file:

diff -r 7063bdada583 common/autoconf/libraries.m4

--- a/common/autoconf/libraries.m4
+++ b/common/autoconf/libraries.m4
@@ -1080,7 +1080,7 @@
          fi
        fi
      done
-    llvm_version=$("${LLVM_CONFIG}" --version | sed 's/\.//; s/svn.*//')
+    llvm_version=$("${LLVM_CONFIG}" --version | sed [ 
's/\(^[0-9]\)*.\([0-9]*\).*/\1\2/; s/svn.*//' ])
      LLVM_CFLAGS="${LLVM_CFLAGS} -DSHARK_LLVM_VERSION=${llvm_version}"

      unset LLVM_LDFLAGS

I tried building locally (Ubuntu 14.04 with llvm 3.4) but it failed with 
undefined references at link time:

/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5b7): undefined reference to `setupterm'
/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5e0): undefined reference to `tigetnum'
/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5e9): undefined reference to `set_curterm'
/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5f1): undefined reference to `del_curterm'
collect2: error: ld returned 1 exit status

I'm not familiar enough with the hotspot source changes to provide a 
meaningful review, but when it's approved I could still push the whole 
thing.

/Erik

On 2015-01-08 12:01, 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.
> - 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).
> - 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.
> - In allocation.hpp, exclude the operator overrides for new etc, LLVM
> does allocations itself, and this would blow up.
> - 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.
> - 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
>>>>>
>


