zero debug still broken after 8189871

Thomas Stüfe thomas.stuefe at gmail.com
Fri Nov 24 18:49:52 UTC 2017


Thanks, you too!

..Thomas

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

> Ok, I‘ll have at this on Sunday evening. Enjoying my weekend now.
>
> Have a nice weekend.
>
> Adrian
>
> On Nov 24, 2017, at 6:59 PM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
>
>
> 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-x86_64-normal-zero-release MAKE_VERBOSE=y QUIETLY= LOG=debug
>> make clean CONF=linux-x86_64-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
>> MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-x86_64-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/specialized_oop_closures.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::verify_types() [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<decorators>::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<T>::value, T>::type
>> RawAccessBarrier<decorators>::atomic_cmpxchg_maybe_locked(T, void*, T)
>> [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators
>> = 1030ul; typename EnableIf<AccessInternal::PossiblyLockedAccess<T>::value,
>> T>::type = oop]’
>> >>
>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51:
>>  required from ‘static T RawAccessBarrier<decorators>::atomic_cmpxchg(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::atomic_cmpxchg(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::atomic_cmpxchg(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::atomic_cmpxchg_reduce_types(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::atomic_cmpxchg(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<decorators>::oop_atomic_cmpxchg(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 ‘STATIC_ASSERT_FAILURE<false>’ used in nested name
>> specifier
>> >>   typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \
>> >>                             ^
>> >>
>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33:
>> note: in definition of macro ‘PASTE_TOKENS_AUX2’
>> >> #define PASTE_TOKENS_AUX2(x, y) x ## y
>> >>                                 ^
>> >>
>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28:
>> note: in expansion of macro ‘PASTE_TOKENS_AUX’
>> >> #define PASTE_TOKENS(x, y) PASTE_TOKENS_AUX(x, y)
>> >>                            ^
>> >>
>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16:
>> note: in expansion of macro ‘PASTE_TOKENS’
>> >>   typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \
>> >>                ^
>> >>
>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5:
>> note: in expansion of macro ‘STATIC_ASSERT’
>> >>     STATIC_ASSERT((HasDecorator<decorators,
>> INTERNAL_VALUE_IS_OOP>::value || // oops have already been validated
>> >>     ^
>> >> --
>> >>
>> >> with
>> >>
>> >>
>> CONFIGURE_COMMAND_LINE:=--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
>> STATIC_ASSERT is failing here. Does anyone have an idea?
>> >>
>> >>
>> >> Thanks, Thomas
>> >>
>>
>>
>


More information about the hotspot-dev mailing list