|
On 7/26/18 12:15, Daniel D. Daugherty wrote:
We
entered RDP2 today (07.26). So only P1 and P2 bug fixes allowed.
Sorry, I confused 07.26 with 07.28.
Then it is 12 only.
Thanks,
Serguei
Dan
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
Hi
Jc,
Good idea.
I was thinking about something like this.
Thanks,
Serguei
On 7/26/18 10:40, JC Beyler wrote:
Hi Serguei,
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
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:
--
--
|
