RFR: (S) 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources

Jon Masamitsu jon.masamitsu at oracle.com
Thu Aug 7 18:20:45 UTC 2014


On 08/07/2014 03:01 AM, Dmitry Fazunenko wrote:
> Jon,
>
> Thanks for looking!
> I love printing as much debug info as possible. But in this case I 
> have nothing to add.
> BTW, the deduplication tests are full of various System.out.prinltn(), 
> so I think the it will be enough information in case of failure.
>
> I modified a little the code to make test fail. The jtr is attached. 
> Please let me know if you believe that more data need to be printed.

Yes, lots of output on failures.  I looked for some output that told
me the addresses of the two strings (the two that don't verify)
and the addresses of their char arrays.  I couldn't find it.
I think if I were debugging a failure, that's the first thing I would
want to see.

Jon

>
> Thanks,
> Dima
>
> On 06.08.2014 23:56, Jon Masamitsu wrote:
>> Dima,
>>
>> If the test fails, can you print the strings with System.out.println() or
>> System.err.println()?  Any information about the strings might be
>> useful to understand why deduplication didn't work or why the
>> test thinks the deduplication didn't work (in case something
>> happens that the test doesn't expect)?
>>
>> Jon
>>
>> On 8/6/2014 8:53 AM, Dmitry Fazunenko wrote:
>>> Hi,
>>>
>>> Would you please look at the simple fix of String Deduplication tests.
>>>
>>> Description:
>>>
>>> When string deduplication has happened /s1.equals(s2)/ will be 
>>> equivalent to /s1 == s2/
>>> Deduplication is performed in a separate thread so it could be 
>>> delayed a bit.
>>> Tests are away about possible delay and give another chance if 
>>> deduplication hasn't
>>> happened by the moment of check.
>>> But tests wait for deduplication in infinitive loop, so if 
>>> deduplication doesn't work the tests
>>> will timeout, leaving hanging VM after. Which is not very elegant.
>>>
>>> The fix is simple: replace infinitive loops with limited ones and 
>>> report failure.
>>> The logic of the tests hasn't changed.
>>>
>>> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
>>> https://bugs.openjdk.java.net/browse/JDK-8050464
>>>
>>> Any comments are welcome.
>>>
>>> Thanks,
>>> Dima
>>>
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20140807/12ab2b05/attachment-0001.html>


More information about the hotspot-gc-dev mailing list