RFR: 8204504: Fix for 8198285 breaks slowdebug builds

[Erik Österlund]

Hi Roman,

Thanks for the review.

/Erik

On 2018-06-08 11:58, Roman Kennke wrote:
> 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
>