RFR: 8204504: Fix for 8198285 breaks slowdebug builds

[Markus Gronlund]

Hi Erik,

I have successfully tested your patch for building Windows slowdebug.

Looks good and thank you for quickly addressing this.

Thanks
Markus

-----Original Message-----
From: Erik Österlund 
Sent: den 7 juni 2018 17:32
To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
Subject: RFR: 8204504: Fix for 8198285 breaks slowdebug builds

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