Re: RFR 8208303: Track JNI failures and fail tests

Thu, 26 Jul 2018 12:14:45 -0700

Yes, of course it has to be well tested before the push.
Does it make sense to plan it to push to 11 (after th testing is done)?

Thanks,
Serguei


On 7/26/18 12:08, Daniel D. Daugherty wrote:
Please make sure this fix is well tested in Mach5 prior to pushing.
In particular, I'm focused on reducing the noise in Mach5 tier[1-3]
so adding any new failures there will make me grumpy :-)

Dan


On 7/26/18 3:03 PM, JC Beyler wrote:
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:


Thanks!
Jc

On Thu, Jul 26, 2018 at 10:46 AM serguei.spit...@oracle.com <serguei.spit...@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.spit...@oracle.com <serguei.spit...@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:

Thanks,
Jc



--

Thanks,
Jc



--

Thanks,
Jc


Reply via email to