The JVM often derives UTF8 strings from Java objects when directly composing diagnostic messages (logs, errors, etc.).

There are various corner cases where a Java object might have a null field, or where the object reference itself is null. If the JVM directly derives a diagnostic string from such a null, it may crash without telling the user anything helpful.

This kind of failure is rare, but possible. (See JDK-8357917 for an example.) There is no particular advantage in crashing when it happens; rather, we should be substituting a readable string (like "(null)") in place of the missing data.

Note: The debug build might throw an assert for the null. That's OK; the debug build should help us find out unintentional nulls. I'm talking about product builds, where the missing assert allows the VM to crash with no useful message.

In particular, java_lang_String::as_utf8_string should be hacked to return "(null)" for a null string, at least in non-debug builds. There may be other places where we derive diagnostic strings from Java objects, as well.

Suggested fix for Java strings:

diff --git a/src/hotspot/share/classfile/javaClasses.cpp b/src/hotspot/share/classfile/javaClasses.cpp
index dca5208370c..7dbf972163b 100644
--- a/src/hotspot/share/classfile/javaClasses.cpp
+++ b/src/hotspot/share/classfile/javaClasses.cpp
@@ -645,6 +645,9 @@ char* java_lang_String::as_utf8_string(oop java_string) {
 }
 
 char* java_lang_String::as_utf8_string(oop java_string, size_t& length) {
+ NOT_DEBUG( if (java_string == nullptr) return "(null)" );
+ NOT_DEBUG( if (!is_instance(java_string)) return "(non-string)" );
+ // An assert in the next call will catch bad inputs in debug builds:
   typeArrayOop value = java_lang_String::value(java_string);
   // `length` is used as the incoming number of characters to
   // convert, and then set as the number of bytes in the UTF8 sequence.