In debug builds the contents of a JNIHandleBlock gets filled with badJNIHandle under various circumstances. This is intended to help catch bad JNI handle usage. In a debug build, if a JNI handle resolves to this value we'll assert. However, resolve_external_guard treats this value specially, returning NULL instead of asserting.

This special handling by resolve_external_guard is problematic for the new Access API (in part because it's problematic for some GCs). The handling of this special value can't be correctly done at the resolve level, because between the check and the Access some other thread could cause the location to be set to the special value. To correctly handle it would require deep and complex intrusion of this highly specific and debug-only feature into the Access mechanism.

For the intended purpose of catching bad JNI handle usage while sometimes normalizing some to NULL, we mostly don't need such a special value. We can instead use NULL directly, and get largely the same effect.