zero debug still broken after 8189871 (original) (raw)

Thomas Stüfe thomas.stuefe at gmail.com
Fri Nov 24 17:59:05 UTC 2017

On Fri, Nov 24, 2017 at 6:42 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote:

Just built successfully on Debian unstable with:

CONF=linux-x8664-normal-zero-release MAKEVERBOSE=y QUIETLY= LOG=debug make clean CONF=linux-x8664-normal-zero-release ; sh ./configure --with-jvm-variants=zero --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32 MAKEVERBOSE=y QUIETLY= LOG=debug CONF=linux-x8664-normal-zero-release debug is broken. Release works. You must build with --with-debug-level=fastdebug or slowdebug to get the error.

Did a „hg pull && hg update —clean“ prior that.

Luckily, I have an SSH client on my iPhone ;). :)

..Thomas

Adrian

> On Nov 24, 2017, at 6:26 PM, John Paul Adrian Glaubitz <_ _glaubitz at physik.fu-berlin.de> wrote: > > That’s odd. I just built Zero successfully a few hours ago after „hg pull && hg update —clean“. > > If there had been an issue, I would have run into it. > > Will try to test in an hour, currently on mobile. > > Adrian > >> On Nov 24, 2017, at 6:21 PM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote: >> >> Hi all, >> >> seems that "8191663: Zero variant broken after 8189170 and 8189871" was alone not sufficient to fix zero debug. >> >> When building zero (fast|slow)debug, I get this error: >> >> --- >> In file included from /shared/projects/openjdk/jdk- hs/source/src/hotspot/share/gc/shared/specializedoopclosures.hpp:28:0, >> from /shared/projects/openjdk/jdk- hs/source/src/hotspot/share/oops/objArrayOop.cpp:26: >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp: In instantiation of ‘void AccessInternal::verifytypes() [with long unsigned int decorators = 2048ul; T = volatile oop]’: >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:905:32: required from ‘T AccessInternal::load(P*) [with long unsigned int decorators = 2048ul; P = volatile oop; T = volatile oop]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:450:50: required from ‘static P Access::load(P*) [with P = volatile oop; long unsigned int decorators = 2048ul]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/ oops/accessBackend.inline.hpp:247:34: required from ‘static typename EnableIf<AccessInternal::PossiblyLockedAccess::value, T>::type RawAccessBarrier::atomiccmpxchgmaybelocked(T, void*, T) [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators = 1030ul; typename EnableIf<AccessInternal::PossiblyLockedAccess::value, T>::type = oop]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51: required from ‘static T RawAccessBarrier::atomiccmpxchg(T, void*, T) [with T = oop; long unsigned int decorators = 1030ul]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:619:37: required from ‘static typename EnableIf<HasDecorator<decorators,_ _2048ul>::value, T>::type AccessInternal::PreRuntimeDispatch::atomiccmpxchg(T, void*, T) [with long unsigned int decorators = 289798ul; T = oop; typename EnableIf<HasDecorator<decorators, 2048ul>::value, T>::type = oop]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:637:71: required from ‘static typename EnableIf<(! HasDecorator<decorators,_ _2048ul>::value), T>::type AccessInternal::PreRuntimeDispatch::atomiccmpxchg(T, void*, T) [with long unsigned int decorators = 287750ul; T = oop; typename EnableIf<(! HasDecorator<decorators, 2048ul>::value), T>::type = oop]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:821:67: required from ‘oop AccessInternal::atomiccmpxchgreducetypes(oop, HeapWord*, oop) [with long unsigned int decorators = 287748ul]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:942:60: required from ‘T AccessInternal::atomiccmpxchg(T, P*, T) [with long unsigned int decorators = 262148ul; P = volatile HeapWord; T = oop]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:492:78: required from ‘static T Access::oopatomiccmpxchg(T, P*, T) [with P = volatile HeapWord; T = oop; long unsigned int decorators = 262144ul]’ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:40:78: required from here >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:29: error: incomplete type ‘STATICASSERTFAILURE’ used in nested name specifier _>> typedef char PASTETOKENS(STATICASSERTDUMMYTYPE, LINE)[ _ >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33: note: in definition of macro ‘PASTETOKENSAUX2’ >> #define PASTETOKENSAUX2(x, y) x ## y >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28: note: in expansion of macro ‘PASTETOKENSAUX’ >> #define PASTETOKENS(x, y) PASTETOKENSAUX(x, y) >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16: note: in expansion of macro ‘PASTETOKENS’ _>> typedef char PASTETOKENS(STATICASSERTDUMMYTYPE, LINE)[ _ >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5: note: in expansion of macro ‘STATICASSERT’ >> STATICASSERT((HasDecorator<decorators,_ _INTERNALVALUEISOOP>::value || // oops have already been validated >> ^ >> -- >> >> with >> >> CONFIGURECOMMANDLINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 --with-debug-level=fastdebug --with-jvm-variants=zero --with-native-debug-symbols=internal --disable-precompiled-headers --with-build-jdk=../output-release/images/jdk >> >> on Ubuntu 16.4. x64 >> >> The error also happens in slow and fastdebug, with precompiled headers enabled or not. Release is fine (in a fashion, I need disable-warnings-as-errors to get it built, but I guess that is another bug). >> >> Thanks, ThomasIt seems triggered by "8189871: Refactor GC barriers to use declarative semantics", but I stared at this error message for half an hour now with not much progress... I do not really understand why the STATICASSERT is failing here. Does anyone have an idea? >> >> >> Thanks, Thomas >>

More information about the hotspot-dev mailing list