RFR: 8204504: Fix for 8198285 breaks slowdebug builds
Roman Kennke
rkennke at redhat.com
Fri Jun 8 09:58:26 UTC 2018
Am 07.06.2018 um 17:32 schrieb Erik Österlund:
> Hi,
>
> Recent changes to arraycopying (8198285) broke slowdebug builds on
> windows and solaris.
>
> The problem is that the RawAccessBarrierArrayCopy::arraycopy<decorators>
> function is expanded for a whole bunch of different new cases after JNI
> code started using this API. The reported linking problems:
>
> void
> AccessInternal::arraycopy_arrayof_conjoint<double>(__type_0*,__type_0*,unsigned
> long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
> void
> AccessInternal::arraycopy_arrayof_conjoint<float>(__type_0*,__type_0*,unsigned
> long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
> void AccessInternal::arraycopy_conjoint_atomic<unsigned
> short>(__type_0*,__type_0*,unsigned long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
> void AccessInternal::arraycopy_conjoint_atomic<unsigned
> char>(__type_0*,__type_0*,unsigned long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
> void
> AccessInternal::arraycopy_conjoint_atomic<float>(__type_0*,__type_0*,unsigned
> long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
> void
> AccessInternal::arraycopy_conjoint_atomic<double>(__type_0*,__type_0*,unsigned
> long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
> void AccessInternal::arraycopy_arrayof_conjoint<unsigned
> short>(__type_0*,__type_0*,unsigned long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
> void AccessInternal::arraycopy_arrayof_conjoint<unsigned
> char>(__type_0*,__type_0*,unsigned long)
> /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/solaris-x86_64-normal-server-slowdebug/hotspot/variant-server/libjvm/objs/jni.o
>
>
> ...are all variants that the backend does not yet support as there are
> no current uses of it. And there really are no current uses of these
> still - these are all false positives. However, the code that currently
> chooses whether to use arrayof, conjoing, disjoint heap words, with
> possibly atomic variations, is all checked with if statements. But each
> case of the if statements are compiled in the template expansion despite
> being statically known to be dead code in a whole bunch of template
> expansions. The optimized code generation is clever enough to just
> ignore that dead code, while the slowdebug builds on windows and solaris
> complain that this dead code (that was only spuriously expanded by
> accident but is never called) does not exist.
>
> The solution I propose to this is to fold away the different cases the
> linker is complaining about using SFINAE instead of if statements. That
> way, they are never template expanded spuriously when it is statically
> known that they will not be called; they are never considered as valid
> overloads.
>
> I have verified on a Solaris x86 machine that it did not build before,
> but builds fine with this patch applied.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8204504/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8204504
>
> Thanks,
> /Erik
OMG WTF templates voodoo. ;-)
Patch is ok.
Thanks for fixing this!
Roman
More information about the hotspot-dev
mailing list