[aarch64-port-dev ] RFC: using gtest to test AArch64 MacroAssembler

[Andrew Haley]

On 2/28/19 10:36 AM, Nick Gasson wrote:
> On 28/02/2019 18:03, Andrew Haley wrote:
>>
>> I'll pass this one back to you: which classes of bugs in locks would
>> this new test *not* detect? Are they important? What could be done
>> about that?
>>
> 
> It doesn't detect bugs caused by races between threads within 
> fast_lock/unlock, i.e. something that would require us in the test to 
> set up some state, start running the code, and then change that state 
> before a certain instruction is executed. Or bugs caused by using the 
> wrong memory ordering semantics.
> 
> Yes they are important.
> 
> It would certainly be possible to create multiple threads inside the 
> gtest test and then run a mini stress test. But that seems to be 
> duplicating a lot of what jcstress already does for us. So I guess the 
> question is, is there some locking behaviour that we can't test with 
> assertions in a single-threaded gtest, and if it was wrong wouldn't 
> cause a jcstress failure? I'm not sure so I'll need to think a bit more 
> about that...

That's fine. It's just that I'm trying not to have to guess which
failures this new test will detect, and which ones it won't. I'm not
saying that the test isn't useful.

So, it helps us detect cases that jcstress doesn't. I guess if we test
the slow and the fast paths separately, we can hope that the jcstress
test will do the rest.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671