> On 24 Oct 2016, at 23:24, Christian Thalinger <cthalin...@twitter.com> wrote: > > >> On Oct 24, 2016, at 3:48 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: >> >> Adding build-dev, which should be included when discussing build issues. For >> any new readers, please see [1] for the full discussion. >> In theory it is possible to compile against and run on the exploded image >> during the build, but I do not recommend it. Igor is correct in the build >> team being against that design. The rationale is that it adds a lot of >> complexity to the build. The exploded image cannot be safely run until all >> java modules have been compiled as it introduces races. Maintaining the >> build with such a construct will be very brittle when other changes are >> made. We did allow the gensrc for jdk.vm.ci to run in this way for a short >> time, since it was only supported on Linux x64, where these races are rarer, >> but if this would ever need to be built on Windows, we would be in trouble >> quickly. Luckily, jdk.vm.ci was able to refactor away from needing this >> annotation processing for that module. >> I certainly prefer the reflection solution proposed here, but find it sad >> that it's needed. >> > > The problem I have with this solution is that jdk.vm.ci code is now > restricted to JDK N-1 code. This might be ok right now because we are able > to work around that issue with reflection but when important features like > Valhalla come around this is a problem. > > Value types will be hugely important for JVMCI and its compilers and we > simply cannot just skip one JDK release just because the build system can’t > handle it.
I agree. However, I suspect large parts of the JDK will also want to leverage Valhalla so I’m guessing the build problem will have to be solved anyway at some point. Maybe it worth filing a tracking bug to revert these changes at that time. -Doug > >> >> /Erik >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024743.html >> >> On 2016-10-19 21:54, Igor Veresov wrote: >>> >>>> On Oct 19, 2016, at 12:47 PM, Christian Thalinger <cthalin...@twitter.com> >>>> wrote: >>>> >>>> >>>>> On Oct 19, 2016, at 9:40 AM, Vladimir Kozlov <vladimir.koz...@oracle.com> >>>>> wrote: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8168317 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~kvn/8168317/webrev/ >>>>> >>>>> When Graal is built as part of JDK it requires first to build an >>>>> annotation processor using boot jdk 8. >>>>> After JDK-8167180 changes Services class is referenced by annotation >>>>> processor but the code is using jdk 9 Module API and it can't be used >>>>> with jdk 8. >>>> >>>> I left a comment in the bug: Permalink >>>> >>>> Basically, it should be possible to use the newly built javac to compile >>>> the annotation processors. Erik? >>> >>> It’s not only about compilation it’s about running it on the bootstrap JDK, >>> which in currently 8. >>> >>> igor >>> >>>> >>>> Can you paste or upload the .gmk file? >>>> >>>>> >>>>> Use reflection instead of Module API and use code only for running with >>>>> jdk 9. >>>>> >>>>> Testing with JPRT and JDK build of Graal. >>>>> >>>>> Thanks, >>>>> Vladimir >>>> >>> >> >
