RFR: 8300079: SIGSEGV in LibraryCallKit::inline_string_copy due to constant NULL src argument

[Tobias Hartmann]

On Fri, 20 Jan 2023 11:57:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The `StringUTF16.compress` variant of `LibraryCallKit::inline_string_copy` does not properly handle a constant null `src` argument that can happen when the `char[] data` argument of `String::copyValueOf` is null:
> 
> https://github.com/openjdk/jdk/blob/7bf0d1465e73d83aae30f1cd9fd318af9e9c1b70/src/java.base/share/classes/java/lang/String.java#L4284-L4285 ->
> https://github.com/openjdk/jdk/blob/7bf0d1465e73d83aae30f1cd9fd318af9e9c1b70/src/java.base/share/classes/java/lang/String.java#L301-L302 ->
> https://github.com/openjdk/jdk/blob/7bf0d1465e73d83aae30f1cd9fd318af9e9c1b70/src/java.base/share/classes/java/lang/String.java#L4504-L4511
> 
> Although the intrinsified code is never executed because we throw a `NullPointerException` from (non-inlined) `rangeCheck`, we need to make sure a constant null is properly handled.
> 
> I manually inspected similar C2 intrinsics and found another potential issue in `LibraryCallKit::inline_mulAdd` where we should call `must_be_not_null` on `in` as well (even if it might not be possible with current code, let's better be safe than sorry).
> 
> All the other changes are simple refactorings for better readability.
> 
> Thanks,
> Tobias

Thanks for the review, Roland!

Being paranoid, I double-checked my refactoring and noticed several `Value` calls with a wrong receiver. Turns out that has always been wrong. I fixed it.

-------------

PR: https://git.openjdk.org/jdk/pull/12112