RFR: String Density/Compact String JEP 254 (original) (raw)

Roland Westrelin roland.westrelin at oracle.com
Thu Oct 8 12:02:16 UTC 2015

Shouldn’t LibraryCallKit::inlinestringtoBytesU() and LibraryCallKit::inlinestringgetCharsU() 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::generateslowarraycopy() 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.

macroAssemblersparc.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 macroAssemblersparc.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.

More information about the hotspot-dev mailing list