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

[Nick Gasson]

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...

Thanks,
Nick