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

David Holmes david.holmes at oracle.com
Fri Oct 14 13:10:37 UTC 2016


On 14/10/2016 10:11 PM, Christian Tornqvist wrote:
> Hi Staffan/David,
>
> I looked at how the other platforms deal with it, they throw an
> IllegalArgumentException when they fail to open the file. I think it makes
> sense for Windows to do the same, please see the updated webrev with IAE
> instead of a NPE:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8159799/webrev.01/

I still find IAE a little odd in this context, but okay - consistency 
counts for a lot. :)

Thanks,
David

> Thanks,
> Christian
>
> -----Original Message-----
> From: Staffan Larsen [mailto:staffan.larsen at oracle.com]
> Sent: Friday, October 14, 2016 2:19 AM
> To: Christian Tornqvist <christian.tornqvist at oracle.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8159799 - Tests using jcmd fails intermittently with
> Could not open PerfMemory on Windows
>
> Thanks for getting to the bottom of this!
>
> The fix looks good. Perhaps, as David points out, FileNotFoundException is a
> better choice but that requires more changes as FileNotFoundException is not
> used anywhere else in the JVM.
>
> Thanks,
> /Staffan
>
>> On 13 Oct 2016, at 20:09, Christian Tornqvist
> <christian.tornqvist at oracle.com> 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.
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>
>


More information about the hotspot-runtime-dev mailing list