RFR (M) 8224079: ExceptionJniWrapper for the Strace test suite

[Jean Christophe Beyler]

Hi all,

I was wanting to continue on deploying the ExceptionJniWrapper and the
first on the list was this one C++ file. It is used by various Strace tests
and I thought I'd stop at just this one to make it easier for reviewing.

Webrev: http://cr.openjdk.java.net/~jcbeyler/8224079/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8224079

The biggest thing to note is that the error messages change a bit,
originally if the native code noticed a problem it would return either 1 or
2, providing a message in Java land:

    a return of 1 would provide a message containing (OutOfMemoryError or
StackOverflow)
    a return of 2 would provide a generic message such as  Unexpected
exception...

Now 1 would give just a generic internal error but it would be with a
message such as:
FATAL ERROR in native method: JNI method CallIntMethod : internal error
from StackTraceController.cpp : 48
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at
nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at
nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at
nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at
nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at
nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at
nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
....

and you would guess it is either an OOM or a stack overflow. And 2 actually
now gives you which method failed. So it's a win for the 2 case, for the 1
there is an extra step that, for me, seemed relatively straight forward.

I can change the code slightly for the 1 case to make the error message
more specific and closer to the original but I was not sure it was worth
it.... What do you all think?

Thanks for your help,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190516/e3f37b34/attachment-0001.html>