RFR(XS): 8159799 - Tests using jcmd fails intermittently with Could not open PerfMemory on Windows

[David Holmes]

Hi Christian,

Great find on getting to the bottom of this!

However ...

On 14/10/2016 4:09 AM, Christian Tornqvist wrote:
> Hi everyone,
>
> Please review this small fix for an intermittent issue we've seen when
> running tests concurrently that use jcmd/jstack.
>
> When running jcmd, we enumerate the perfdata files and then open them one by
> one to read things like main class names etc. If the perfdata file
> disappears (because the Java process exited) before we get to it, we end up
> with different exceptions depending on where in the code we are.
>
> The code at:
>
> http://hg.openjdk.java.net/jdk9/hs/jdk/file/3d3f338b5aea/src/jdk.jcmd/share/
> classes/sun/tools/common/ProcessArgumentMatcher.java#l88
>
> handles this, the problem is that if we get all the way to
> open_sharedmem_object() in the JVM, we'll throw a java.lang.Exception which
> isn't caught by this. The fix is to throw a NPE instead of Exception and let
> the existing code handle this.

... that seems the wrong fix. NPE is a very specific exception with a 
very clear meaning. I'm not at all sure where the existing NPE may come 
from, but it seems to me that there should be a more specific exception 
defined for this condition that is thrown by the VM and anticipated by 
the Java code. Why is there not a FileNotFoundException for example ?? 
The current NPE seems incidental.

As a quick fix to improve test stability I can agree to this but I'd 
like to see a RFE to properly coordinate the VM and Java sides of this 
with a well defined (set of) exception(s).

Thanks,
David

> Fix has been tested locally and with 30 JPRT runs (with concurrency patch
> applied), also managed to reproduce and verify this fix locally using a
> debugger to trigger the race.
>
>
>
> Webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8159799/webrev.00/
>
>
>
> Bug (unfortunately not visible):
>
> https://bugs.openjdk.java.net/browse/JDK-8159799
>
>
>
> Thanks,
>
> Christian
>
>
>
>
>