RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

Tristan Yan tristan.yan at oracle.com
Mon Jan 13 06:21:05 UTC 2014


Hi All
I add more trace output to track down possible reason of this failure. 
Please help to review it again.

http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.05/
Thank you
Tristan

On 01/10/2014 07:20 AM, Tristan Yan wrote:
> Hi David
> I wasn't able to reproduce this failure either in local or in our same 
> binaries running(This is a continuous running with same JDK binaries). 
> So intention for this code change is bringing this test back;  add 
> some debug info and try to avoid possible issues in this test. I agree 
> this code change won't solve the failure happened. But this test was 
> put into ProblemList two years ago better move for this is move out it 
> from ProblemList and trace down the issue in our normal nightly.
> Thank you
> Tristan
>
> On 01/10/2014 06:35 AM, David Holmes wrote:
>> On 9/01/2014 10:14 PM, Alan Bateman wrote:
>>> On 09/01/2014 11:27, David Holmes wrote:
>>>>
>>>> Okay I think I get it now. Both MonitorTest and WaitersTest use the
>>>> Context class, so if both tests run in the same VM the second test
>>>> will see the static total_turns_taken and "turn" in the state they
>>>> were left from the first test - hence the second test will always
>>>> fail. The bug report suggests making the tests othervm to avoid the
>>>> problem but instead you have changed from using static state to
>>>> instance state so that there is no interference.
>>> I haven't been following this one closely but I thought that jtreg
>>> created a class loader for each test (irrespective of mode) so I
>>> wouldn't expect statics to be an issue.
>>
>> That aside DemoRun forks off its own JVM to run a given test anyway!
>>
>> So I don't understand how the proposed fixes could actually be 
>> addressing the hangs that are occurring. Even if the statics were 
>> being shared I don't see how that leads to the failure mode in the 
>> bug report.
>>
>> David
>>
>>> -Alan.
>




More information about the core-libs-dev mailing list