fastdebug builds broken for jdk9/hs tree?

[Severin Gehwolf]

On Fri, 2016-04-29 at 18:11 +1000, David Holmes wrote:
> On 29/04/2016 5:39 PM, Severin Gehwolf wrote:
> > 
> > On Fri, 2016-04-29 at 17:28 +1000, David Holmes wrote:
> > > 
> > > Hi Severin,
> > > 
> > > On 29/04/2016 2:35 AM, Severin Gehwolf wrote:
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Recently, a fastdebug build of a server JVM fails for me on Linux
> > > > x86_64 with older sys/sdt.h and/or GCC. The same failure shows up since
> > > > a couple of days on the Zero builder[1]:
> > > > 
> > > > /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp: In static member function ‘static void ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)’:
> > > > /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp:148: error: cannot reload integer constant operand in ‘asm’
> > > > /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp:148: error: cannot reload integer constant operand in ‘asm’
> > > > gmake[4]: *** [/home/sgehwolf/openjdk9-hs-pristine/build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/libjvm/objs/classLoadingService.o] Error 1
> > > > gmake[4]: Leaving directory `/home/sgehwolf/openjdk9-hs-pristine/hotspot/make'
> > > > 
> > > > On that line is a macro for dtrace:
> > > > 
> > > > void ClassLoadingService::notify_class_loaded(InstanceKlass* k, bool shared_class) {
> > > >   DTRACE_CLASSLOAD_PROBE(loaded, k, shared_class); // <<< This fails
> > > > 
> > > > If I compile the same file *without* -DDTRACE_ENABLE it compiles fine.
> > > > A slowdebug build compiles fine too. I was able to *reproduce* this on
> > > > RHEL 6. It *does not* reproduce on F23.
> > > > 
> > > > I had a brief look at the preprocessed compilation unit for
> > > > classLoadingService and the code that gets included for the dtrace
> > > > macro looks different.
> > > > 
> > > > So here the questions:
> > > > 
> > > > 1.) Has anything related to dtrace macros changed recently?
> > > > 2.) Has anybody else been seeing this?
> > > This would seem to be an issue with the content of sdt.h and the version
> > > of gcc being used. Have either of those changed at your end? This seems
> > > external to the OpenJDK sources ... though perhaps there is a build
> > > related issue? How recently did this start - did it happen after the
> > > switch to the new hotspot build?
> > It might be. I'll investigate. I'm not aware of any gcc/systemtap
> > changes, but I'll have a closer look.
> > 
> > I take it that's a no to question 1 above?
> Nothing on our side, and there is no asm in anything in our sources 
> AFAICS so I assume it is something in sdt.h. Only change here was a few 
> weeks back for jigsaw:
> 
>   > hg log -p ./os/posix/dtrace/hotspot_jni.d
> changeset:   10487:c558850fac57
> tag:         jdk-9+111
> parent:      10484:0de4d895a5c8
> user:        alanb
> date:        Thu Mar 17 19:04:01 2016 +0000
> summary:     8142968: Module System implementation
> 
> diff -r 0de4d895a5c8 -r c558850fac57 src/os/posix/dtrace/hotspot_jni.d
> --- a/src/os/posix/dtrace/hotspot_jni.d
> +++ b/src/os/posix/dtrace/hotspot_jni.d
> @@ -300,6 +300,8 @@
>     probe GetLongField__return(uintptr_t);
>     probe GetMethodID__entry(void*, void*, const char*, const char*);
>     probe GetMethodID__return(uintptr_t);
> +  probe GetModule__entry(void*, void*);
> +  probe GetModule__return(void*);
>     probe GetObjectArrayElement__entry(void*, void*, uintptr_t);
>     probe GetObjectArrayElement__return(void*);

OK.

Thanks, David!

Cheers,
Severin

> David
> 
> > 
> > Cheers,
> > Severin
> > 
> > > 
> > > Cheers,
> > > David
> > > -----
> > > 
> > > > 
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/227/console
> > > >