RFR: String Density/Compact String JEP 254

[Roland Westrelin]

>> Shouldn’t LibraryCallKit::inline_string_toBytesU() and LibraryCallKit::inline_string_getCharsU() use an ArrayCopyNode (maybe an improvement/cleanup for later)?
>> 
>> Same is true for PhaseStringOpts::arraycopy
> 
> The problem with using an ArrayCopyNode is that it requires 
> 
>  // (2) src and dest arrays must have elements of the same BasicType
> 
> otherwise PhaseMacroExpand::generate_slow_arraycopy() is used. Since for ..toBytesU() and ..getCharsU() we are copying from char[] to byte[] or vice-versa, we cannot use ArrayCopyNode without modifying the macro expansion.
> 
> I think the same applies to PhaseStringOpts::arraycopy() where we are copying between two byte arrays because the ArrayCopyNode does not "know" that we can always copy chars since the offsets are guaranteed to be char aligned.
> 
> I created a JEP subtask to keep track of this:
> 
> https://bugs.openjdk.java.net/browse/JDK-8139132
> 
> We may convert this to an "enhancement" after integrating the changes.

That sounds good to me.

>> macroAssembler_sparc.cpp 
>> 
>> I don’t think you should reference c2 stuff outside c2:
>> 
>> 4440   if (ae == StrIntrinsicNode::LU || ae == StrIntrinsicNode::UL) {
> 
> I added '#ifdef COMPILER2' statements to guard the C2 specific string methods in macroAssembler_sparc.cpp.

That still doesn’t feel right but I don’t see where the definitions should go either so we can leave it like that and change it if that code becomes shared.

Roland.