[concurrency-interest] a volatile bug?

Kirk Pepperdine kirk at kodewerk.com
Mon May 21 04:19:16 EDT 2012


Didn't mean to imply this was going to be easy nor error prone. I fully appreciate the difficulties. But we are dealing with a class of bugs that are statistical in nature.. those stats change based on a uncontrollable number of environmental conditions which implies the problem is intractable. That said, we still must test and if the problem has moved from one of a binary (worked, didn't work) to a statistical one, it seems that the testing must move in that direction also... agreed it cannot be perfect but that's no reason for not starting.

For example, I had a biased locking bench that failed occasionally. By making numerous runs I was able to detect cases where the biased locking optimization wasn't applied. All I could sort out is there was some sort of race condition that was affected by were the JVM was loaded into memory.. pure speculation but that was one variable that differed between runs. If I could speculate more, my guess is that there was an underlying time sensitive optimization that some times won and when it did it precluded biased locking from begin applied. Most of this analysis came from a statistical treatment of the benchmarking results.

Another example though not a concurrency one. I have a bench that will readjust Java heap based on -XX:NewRatio setting. If the JVM is loaded in low RAM the JVM will adjust the heap in response to a set load. The JVM will *not* resize when the JVM is loaded in higher RAM. Again, you can't see this with a single test.. in fact, you can't see it with a number of tests unless you load the JVM in different memory segments.

Regards,
Kirk

On 2012-05-21, at 12:48 AM, David Holmes wrote:

> My point was that it is very difficult to write tests that trigger different compilation strategies. As it stands unless people play with the compiler strategies via -XX options then these tests will always behave the same way in that regard, so the coverage is not what you might think.
> 
> David
> 
>> -----Original Message-----
>> From: Kirk Pepperdine [mailto:kirk at kodewerk.com]
>> Sent: Monday, 21 May 2012 3:35 AM
>> To: Boehm, Hans
>> Cc: dholmes at ieee.org; Doug Lea; viktor ?lang;
>> concurrency-interest at cs.oswego.edu
>> Subject: Re: [concurrency-interest] a volatile bug?
>> 
>> 
>> I've been rooting around at the hardware level and the best 
>> testing idea I've been able to come up with is to treat this 
>> stuff as a "trait". Test coverage for this stuff is utterly 
>> impossible. I think the best one can do is as you suggested, 
>> write the tests, make them statistical in nature and then make it 
>> easily available so that the community can run the test them 
>> selves. I see this tactic as necessary evil in the future of testing.
>> 
>> Regards,
>> Kirk
>> 
>> On 2012-05-20, at 7:21 PM, Boehm, Hans wrote:
>> 
>>> Good point.  But especially in this area, I still think a 
>> widely available test suite would help a lot.  You might miss the 
>> problem in your test environment, but if you get everyone who has 
>> a threads-related problem and suspects their compiler to run the 
>> suite in their environment, I'd guess you would get reasonable coverage.
>>> 
>>> Hans
>>> 
>>> 
>>>> From: David Holmes
>>>> 
>>>> It is also very difficult to run tests in a way that tests all 
>> possible generated
>>>> code from the JITs. The OSR form can be different from the 
>> "normal" form
>>>> which can be different from a forced compilation via -Xcomp.
>>>> 
>>>> But we definitely need better coverage here.
>>>> 
>>>> David
>>>> 
>>>>> -----Original Message-----
>>>>> From: concurrency-interest-bounces at cs.oswego.edu
>>>>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Doug
>>>>> Lea
>>>>> Sent: Saturday, 19 May 2012 11:25 PM
>>>>> To: viktor ?lang
>>>>> Cc: concurrency-interest at cs.oswego.edu
>>>>> Subject: Re: [concurrency-interest] a volatile bug?
>>>>> 
>>>>> 
>>>>> On 05/19/12 09:16, √iktor Ҡlang wrote:
>>>>>> Wait, what, there's no JMM tests?
>>>>> 
>>>>> There is not, to my knowledge, a "hotspot JMM Test suite"
>>>>> (which is out of my scope).  But there are (three forms of) j.u.c test
>>>>> suites, that together test most JMM requirements.
>>>>> But there ought to be a separate one to mop up coverage holes.
>>>>> 
>>>>> -Doug
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Concurrency-interest mailing list
>>>>> Concurrency-interest at cs.oswego.edu
>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>> 
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> 
>> 
> 




More information about the Concurrency-interest mailing list