[PATCH] Fix Shark build in JDK9

Tue Jan 13 21:41:04 UTC 2015

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