ADDITIONAL SYSTEM INFORMATION :
In fact the bug can be triggered at both macOS Big Sur and Ubuntu 18.04.2 LTS.
More detailed:
Linux:
Ubuntu 18.04.2 LTS
CPU model: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
CPU cores: two octa-core CPUs
Memory: 96452 MB
macOS:
macOS Big Sur
Version 11.2.3 (20D91)
Processor 2.3 GHz Dual-Core Intel Core i5
Memory 8 GB 2133 MHz LPDDR3

We downloaded all the implementations from jdk-8 to jdk-16 on the http://jdk.java.net/ and tested them. The result is that all implementations failed to trigger this bug correctly.

Java - version Output
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.275-b01, mixed mode)

openjdk version "1.8.0_41"
OpenJDK Runtime Environment (build 1.8.0_41-b04)
OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode)

openjdk version "9"
OpenJDK Runtime Environment (build 9+181)
OpenJDK 64-Bit Server VM (build 9+181, mixed mode)

openjdk version "10" 2018-03-20
OpenJDK Runtime Environment 18.3 (build 10+44)
OpenJDK 64-Bit Server VM 18.3 (build 10+44, mixed mode)

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+32)
OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing)

openjdk version "13" 2019-09-17
OpenJDK Runtime Environment (build 13+33)
OpenJDK 64-Bit Server VM (build 13+33, mixed mode, sharing)

openjdk version "14" 2020-03-17
OpenJDK Runtime Environment (build 14+36-1461)
OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

openjdk version "15" 2020-09-15
OpenJDK Runtime Environment (build 15+36-1562)
OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)

openjdk version "16" 2021-03-16
OpenJDK Runtime Environment (build 16+36-2231)
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)

A DESCRIPTION OF THE PROBLEM :
We found that all the hotspot implementations failed to throw any exceptions after StackOverflowError was occurred. But if we add a simple statement to the code, the exception can be triggered correctly. We have simplified the test case, and you can find it below.
In addition, we tested this on other jvm implementations, such as J9 and graalvm. The result is that J9 can correctly throw the exception, but graalvm, like hotspot, also failed to throw the exception correctly.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
First, execute the test case with any hotspot implementation. You can get the "Actual Result", nothing was output.
Second, uncomment the println in the test case and you can get the "Expected Result".

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Exception in thread "main" java.lang.NullPointerException
at microbench.Bug3.m1(Bug3.java:6)
at microbench.Bug3.m2(Bug3.java:20)
at microbench.Bug3.m2(Bug3.java:13)
        ........
ACTUAL -
If we comment the line of code “System.out.println("This is the only diff");”, nothing will be output.

---------- BEGIN SOURCE ----------
public class Bug {

    static Object m1(boolean var0) {
        throw new NullPointerException();
    }

    static boolean m2(boolean var0) {
        boolean var1 = false;

        try {
            var1 = m2(var0);
        } catch (StackOverflowError e) {
            return true;
        }
// System.out.println("This is the only diff");
        if (var1) {
            try {
                m1(var0);
            } catch (StackOverflowError e) { }
        }
        return false;
    }

    public static void main(String[] var0) {
        m2(true);
    }
}
---------- END SOURCE ----------

FREQUENCY : always