[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