RFR: 8204504: Fix for 8198285 breaks slowdebug builds

[Daniel D. Daugherty]

Just for the OpenJDK record: I also tested Erik's patch on my Solaris-X64
server yesterday and builds work again for 'release', 'fastdebug' and
'slowdebug'.

Roman> OMG WTF templates voodoo. ;-)

Yup. I now understand why I wasn't able to fix this 'simple build problem'
quickly myself... :-)

Dan

On 6/8/18 6:07 AM, Erik Österlund wrote:
> 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
>>
>