RFR 8208303: Track JNI failures and fail tests

[JC Beyler]

Hi all,

With the FatalError idea, here is the webrev to consider, note it no longer
changes the tests. If a JNI call fails, then we call FatalError.

Let me know what you think:

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

Thanks!
Jc

On Thu, Jul 26, 2018 at 10:46 AM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> Hi Jc,
>
> Good idea.
> I was thinking about something like this.
>
> Thanks,
> Serguei
>
>
> On 7/26/18 10:40, JC Beyler wrote:
>
> Hi Serguei,
>
> As I was looking at another test bug (
> https://bugs.openjdk.java.net/browse/JDK-8191519); the proposal for that
> bug is to have a JNI call to FatalError to provoke a failure.
>
> If we went down that route, this webrev is simpler, no? Instead of setting
> failure_status and checking it later; just fail fatally and be done with
> it, no? That way, the tests in Java land don't have to be changed actually,
> no?
>
> What would we prefer for tests? Remember there was a failure and test it
> later or fail fast via JNI's FatalError?
>
> Thanks,
> Jc
>
>
> On Thu, Jul 26, 2018 at 10:04 AM serguei.spitsyn at oracle.com <
> serguei.spitsyn at oracle.com> wrote:
>
>> Hi Jc,
>>
>> It looks good to me.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 7/26/18 09:58, JC Beyler wrote:
>>
>> Hi all,
>>
>> The tests in the HeapMonitor subsystem has a lot of JNI calls. There is a
>> need for verification and testing if anything in the JNI subsystem failed
>> unexpectedly.
>>
>> Here is a webrev that tracks if a JNI call does fail and the tests will
>> fail if any JNI call does fail.
>>
>> Could I have a few reviews please for:
>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8208303/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208303
>>
>> Thanks,
>> Jc
>>
>>
>>
>
> --
>
> Thanks,
> Jc
>
>
>

-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180726/937e953c/attachment.html>