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

Nick Gasson nick.gasson at arm.com
Thu Feb 28 08:38:58 UTC 2019


Hi AArch64 devs...

When I was making some changes to the fast_lock and fast_unlock macros 
last month, I found it was very difficult to verify I hadn't broken 
anything using the existing hotspot tests. Also it seems that many of 
the intrinsics have less-than-perfect coverage from the existing jtreg 
tests. But I think most of the assembly code in MacroAssembler and the 
stub routines are quite amenable to unit testing, as it's possible to 
specify their inputs and outputs in terms of registers and some memory 
buffers, and they don't access a lot of global state.

Below is an example of how we might use the existing hotspot gtest 
framework to write unit tests for our assembly code. I've included an 
example of testing fast_lock/unlock (that would fail prior to 8217368 
and 8216350) and the string_compare intrinsic.

http://cr.openjdk.java.net/~ngasson/gtest/webrev.0/

I'm interested whether you think this is useful or not?

IMO the advantages of testing this way over Java tests using jtreg are:

* We guarantee that the intrinsic/macro code will actually be run (i.e. 
we don't have to worry about compiler flags, warmup time, etc.)

* We can precisely control the input - e.g. buffer sizes and alignment - 
which should make it easier to hit corner cases.

* It's possible to write assertions about things that are impossible to 
write functional tests for from Java. E.g. the locking macro failure 
modes just caused a performance degradation which is hard to detect 
unless you can look at the value in the flags register.

* It's much faster to run than jtreg (each test above takes <1ms, plus a 
few hundred ms VM setup time).

* It's all #ifdef AARCH64 so has zero effect on other platforms.

We could also move the assembler smoke test that's currently called from 
aarch64TestHook into gtest, as I don't see a reason to run that every 
time we start the VM in debug mode. (Does aarch64TestHook leak a 
BufferBlob at the moment?)

Thanks,
Nick


More information about the aarch64-port-dev mailing list