Re: [PATCH] Fix Shark build in JDK9
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?
Re: [PATCH] Fix Shark build in JDK9
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
Re: [PATCH] Fix Shark build in JDK9
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/ 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 m
Re: [PATCH] Fix Shark build in JDK9
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
Re: [PATCH] Fix Shark build in JDK9
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
Re: [PATCH] Fix Shark build in JDK9
On 2015-01-08 12:54, Andrew Haley wrote: On 01/08/2015 11:38 AM, Erik Joelsson wrote: 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 That should be in the ncurses-devel package (or whatever it's called on Ubuntu) which I thought was an OpenJDK requirement anyway. Maybe the only problem is that we're not linking with -lncurses. On my machine, "llvm-config --ldflags" outputs: -L/usr/lib/llvm-3.4/lib -lpthread -lffi -ltinfo -ldl -lm But configure filters only -L arguments into LLVM_LDFLAGS. The rest of the -l flags above are already present on the libjvm link line, but before $(LLVM_LIBS). If I explicitly add -ltinfo last on the link line (after LLVM_LIBS), my build succeeds. /Erik
Re: [PATCH] Fix Shark build in JDK9
On 01/08/2015 11:38 AM, Erik Joelsson wrote:
> 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
That should be in the ncurses-devel package (or whatever it's called on
Ubuntu) which I thought was an OpenJDK requirement anyway. Maybe the
only problem is that we're not linking with -lncurses.
Andrew.
Re: [PATCH] Fix Shark build in JDK9
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
Re: [PATCH] Fix Shark build in JDK9
On 01/08/2015 11:31 AM, Roman Kennke wrote: > I guess for my purposes it's good enough to pass some GCC flag to turn > on C++11 support, so that the new LLVM headers can be used. That's all > that I need. But does that work without further changes? Andrew.
Re: [PATCH] Fix Shark build in JDK9
Am Donnerstag, den 08.01.2015 um 21:20 +1000 schrieb David Holmes: > On 8/01/2015 9:05 PM, Roman Kennke wrote: > > Oh and notice that if you try to build it yourself, use a version of > > LLVM < 3.5. In 3.5, C++11 is used/required, and OpenJDK doesn't support > > C++11 yet. (are there any plans about this?) I'd recommend LLVM 3.4.2. > > C++11? We still have workarounds for compilers that don't support C99 :( Well ok, fair enough ;-) I guess for my purposes it's good enough to pass some GCC flag to turn on C++11 support, so that the new LLVM headers can be used. That's all that I need. Roman > > David > > > 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 > > > >>> > >> > > > >
Re: [PATCH] Fix Shark build in JDK9
On 8/01/2015 9:05 PM, Roman Kennke wrote: Oh and notice that if you try to build it yourself, use a version of LLVM < 3.5. In 3.5, C++11 is used/required, and OpenJDK doesn't support C++11 yet. (are there any plans about this?) I'd recommend LLVM 3.4.2. C++11? We still have workarounds for compilers that don't support C99 :( David 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
Re: [PATCH] Fix Shark build in JDK9
Oh and notice that if you try to build it yourself, use a version of LLVM < 3.5. In 3.5, C++11 is used/required, and OpenJDK doesn't support C++11 yet. (are there any plans about this?) I'd recommend LLVM 3.4.2. 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 > >>> > > >
Re: [PATCH] Fix Shark build in JDK9
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 > >>> > > >
Re: [PATCH] Fix Shark build in JDK9
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
Re: [PATCH] Fix Shark build in JDK9
On 8/01/2015 1:10 AM, Erik Joelsson wrote: Hello, On 2015-01-07 15:45, Roman Kennke wrote: Hello there, I made some fixes to the build machinery to be able to build Shark: http://cr.openjdk.java.net/~rkennke/shark-build-top/ Looks fine, but the generated configure script needs to be generated by the script as it also updates a timestamp inside the file. We will still need to update the closed version of the generated script in sync with this. I will be happy to push both when review has passed if you like. http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/ That looks like a simple typo. Looks good to me. This is in hotspot however so will need to go through a hotspot forest and requires 2 reviewers. I think this is trivial enough that it doesn't matter which forest it goes through - better to keep everything in one forest though. I can add my Review to Eriks and that will suffice. David - http://cr.openjdk.java.net/~rkennke/shark-build-jdk/ Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the exact same? Perhaps change into one conditional like this? ifneq ($(findstring $(JVM_VARIANTS), server zero zeroshark),) I'm also pondering if the build_sa conditional could be made simpler, but this is planned to go away before JDK 9 is done so I'm ok with leaving it like this. In particular, it does: - Improve the sed command to figure out the LLVM version. LLVM changed its version string from x.y to x.y.z. The command now correctly strips x.y.z to xy, we're only interested in the first two numbers. I also hand-changed the generated configure, please forgive me ;-) - In hotspot's makefile, I fixed a typo, allowing to build with unzipped debug info. - In JDK's build, I added the ZEROSHARK variant to exclude the SA generation. Notice that this alone doesn't make Shark build and run fine, it still requires some code changes. Those are not related to build-dev though, I will post them to the appropriate lists asap. Can you please review the changes? I would like to push this to build-infra/jdk9. Build changes go directly to jdk9/dev. The build-infra forest is for prototyping things for the build-infra project and has no scheduled pushes to jdk9. Perhaps it would be better to combine the above changes with your source changes and submit reviews separately for hotspot and root/jdk repos instead? /Erik Regards, Roman
Re: [PATCH] Fix Shark build in JDK9
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 > > >
Re: [PATCH] Fix Shark build in JDK9
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? Sure, please go ahead and push the top-level and JDK changes. Thanks a lot! Roman
Re: [PATCH] Fix Shark build in JDK9
On Wed, Jan 7, 2015 at 5:29 PM, 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)?
Hi Roman,
in order to push changes you first have to be a committer (which you are).
As you noticed, external (i.e. external to Oracle) committers can not
push changes to the hotspot repository with the exception of changes
which only touch community-supported platform files (i.e. all files
under src/cpu/{ppc, zero}, src/os/aix, ...)
Besides that you should be technically able to push changes to all
other repositories but you shouldn't do that for changes which require
changes in the closed source files Oracle maintains in parallel to the
OpenJDK sources. These are for example all the files which require the
regeneration of the generated configure script.
Depending on your time constraints it may be reasonable to ask Erik to
push your top-level/jdk changes right into the corresponding hotspot
forest in which you want to do your hotspot changes. Otherwise, if
your top-level/jdk changes are pushed to jdk9/dev it may take up to
two weeks until they arrive for example in jdk9/hs-rt.
Regards,
Volker
PS: by the way, the changes themselves look fine to me:)
> 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?
>
> Roman
>
Re: [PATCH] Fix Shark build in JDK9
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
Re: [PATCH] Fix Shark build in JDK9
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? Roman
Re: [PATCH] Fix Shark build in JDK9
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. /Erik Regards, Roman
Re: [PATCH] Fix Shark build in JDK9
Hi Erik, > >>> I made some fixes to the build machinery to be able to build Shark: > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark-build-top/ > >> Looks fine, but the generated configure script needs to be generated by > >> the script as it also updates a timestamp inside the file. We will still > >> need to update the closed version of the generated script in sync with > >> this. I will be happy to push both when review has passed if you like. > > That would be great. > > > >>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/ > >> That looks like a simple typo. Looks good to me. This is in hotspot > >> however so will need to go through a hotspot forest and requires 2 > >> reviewers. > > ok, I will finish my code-changes to hotspot and propose the whole bunch > > to hotspot-dev separately as you suggested. > Sounds like a good idea, thanks! > >>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/ > >> Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the > >> exact same? Perhaps change into one conditional like this? > > Please have a look at the updated simpler patch I posted right after the > > first one: > > > > http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/ > That indeed looks better. > > 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 :-) Regards, Roman
Re: [PATCH] Fix Shark build in JDK9
On 2015-01-07 16:41, Roman Kennke wrote: Hi Erik, I made some fixes to the build machinery to be able to build Shark: http://cr.openjdk.java.net/~rkennke/shark-build-top/ Looks fine, but the generated configure script needs to be generated by the script as it also updates a timestamp inside the file. We will still need to update the closed version of the generated script in sync with this. I will be happy to push both when review has passed if you like. That would be great. http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/ That looks like a simple typo. Looks good to me. This is in hotspot however so will need to go through a hotspot forest and requires 2 reviewers. ok, I will finish my code-changes to hotspot and propose the whole bunch to hotspot-dev separately as you suggested. Sounds like a good idea, thanks! http://cr.openjdk.java.net/~rkennke/shark-build-jdk/ Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the exact same? Perhaps change into one conditional like this? Please have a look at the updated simpler patch I posted right after the first one: http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/ That indeed looks better. Do you have a bug for this? /Erik Regards, Roman
Re: [PATCH] Fix Shark build in JDK9
Hi Erik, > > I made some fixes to the build machinery to be able to build Shark: > > > > http://cr.openjdk.java.net/~rkennke/shark-build-top/ > Looks fine, but the generated configure script needs to be generated by > the script as it also updates a timestamp inside the file. We will still > need to update the closed version of the generated script in sync with > this. I will be happy to push both when review has passed if you like. That would be great. > > http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/ > That looks like a simple typo. Looks good to me. This is in hotspot > however so will need to go through a hotspot forest and requires 2 > reviewers. ok, I will finish my code-changes to hotspot and propose the whole bunch to hotspot-dev separately as you suggested. > > http://cr.openjdk.java.net/~rkennke/shark-build-jdk/ > Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the > exact same? Perhaps change into one conditional like this? Please have a look at the updated simpler patch I posted right after the first one: http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/ Regards, Roman
Re: [PATCH] Fix Shark build in JDK9
Hello, On 2015-01-07 15:45, Roman Kennke wrote: Hello there, I made some fixes to the build machinery to be able to build Shark: http://cr.openjdk.java.net/~rkennke/shark-build-top/ Looks fine, but the generated configure script needs to be generated by the script as it also updates a timestamp inside the file. We will still need to update the closed version of the generated script in sync with this. I will be happy to push both when review has passed if you like. http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/ That looks like a simple typo. Looks good to me. This is in hotspot however so will need to go through a hotspot forest and requires 2 reviewers. http://cr.openjdk.java.net/~rkennke/shark-build-jdk/ Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the exact same? Perhaps change into one conditional like this? ifneq ($(findstring $(JVM_VARIANTS), server zero zeroshark),) I'm also pondering if the build_sa conditional could be made simpler, but this is planned to go away before JDK 9 is done so I'm ok with leaving it like this. In particular, it does: - Improve the sed command to figure out the LLVM version. LLVM changed its version string from x.y to x.y.z. The command now correctly strips x.y.z to xy, we're only interested in the first two numbers. I also hand-changed the generated configure, please forgive me ;-) - In hotspot's makefile, I fixed a typo, allowing to build with unzipped debug info. - In JDK's build, I added the ZEROSHARK variant to exclude the SA generation. Notice that this alone doesn't make Shark build and run fine, it still requires some code changes. Those are not related to build-dev though, I will post them to the appropriate lists asap. Can you please review the changes? I would like to push this to build-infra/jdk9. Build changes go directly to jdk9/dev. The build-infra forest is for prototyping things for the build-infra project and has no scheduled pushes to jdk9. Perhaps it would be better to combine the above changes with your source changes and submit reviews separately for hotspot and root/jdk repos instead? /Erik Regards, Roman
Re: [PATCH] Fix Shark build in JDK9
I just realized that I posted some unneeded stuff, and that the check for ZERO *or* ZEROSHARK can be made simpler: http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/ Roman Am Mittwoch, den 07.01.2015 um 15:45 +0100 schrieb Roman Kennke: > Hello there, > > I made some fixes to the build machinery to be able to build Shark: > > http://cr.openjdk.java.net/~rkennke/shark-build-top/ > http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/ > http://cr.openjdk.java.net/~rkennke/shark-build-jdk/ > > In particular, it does: > - Improve the sed command to figure out the LLVM version. LLVM changed > its version string from x.y to x.y.z. The command now correctly strips > x.y.z to xy, we're only interested in the first two numbers. I also > hand-changed the generated configure, please forgive me ;-) > - In hotspot's makefile, I fixed a typo, allowing to build with unzipped > debug info. > - In JDK's build, I added the ZEROSHARK variant to exclude the SA > generation. > > Notice that this alone doesn't make Shark build and run fine, it still > requires some code changes. Those are not related to build-dev though, I > will post them to the appropriate lists asap. > > Can you please review the changes? I would like to push this to > build-infra/jdk9. > > Regards, > Roman >
