JDK-8139132 : CompactStrings intrinsics should use ArrayCopyNode
- Type: Enhancement
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 9
- Priority: P4
- Status: Closed
- Resolution: Duplicate
- Submitted: 2015-10-08
- Updated: 2016-04-29
- Resolved: 2016-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 10 |
|---|
10Resolved  |
Related Reports
|
Duplicate :
|
|
|
Relates :
|
Description
LibraryCallKit::inline_string_toBytesU(), LibraryCallKit::inline_string_getCharsU() and PhaseStringOpts::arraycopy() use direct calls to array copy stub. Instead an ArrayCopyNode should be emitted. Currently, this does not work because an ArrayCopyNode requires // (2) src and dest arrays must have elements of the same BasicType Since for ..toBytesU() and ..getCharsU() we are copying from char[] to byte[] or vice-versa, we cannot use ArrayCopyNode without modifying the macro expansion. 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.
Comments
|