RFR: String Density/Compact String JEP 254

[Tobias Hartmann]

Thanks, Roland.

On 08.10.2015 14:02, Roland Westrelin wrote:
>>> 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.

Yes, I agree. The same ifdefs were added to the x86 C2 code.

Best,
Tobias