Test Methodology

The JEP in question adds several new APIs, as well as inter-operating with some existing APIs. Both should be tested.

New APIs

• MemorySegment and MemoryAddress; These are classes with several thread-safety concerns. Data races should not be able to crash the VM. This can be verified using stress testing. More general API testing can be used to verify that unsafe operations are caught, and exceptions are thrown.
• MemoryAccessHandles provides methods for creating var handles that can be used to do foreign memory access, in tandem with MemorySegment. This uses among other things template files and runtime bytecode generation. Care should be taken when testing that the bytecode verifier is run on the generated classes when running test (since this is not always the case by default).
• The MemorLayout API; a hierarchy of classes that can be used to describe memory layouts. These should be tested through standard API testing based on the specification.

Interop with existing APIs

• ByteBuffer; it is possible to convert between a MemorySegment and a ByteBuffer. Testing should verify that existing ByteBuffer functionality continues to work, including JNI APIs such as GetDirectBufferAddress. Testing should also verify that converting between one type and the other (repeatedly) is a loss-less operation, in particularly: when converting from a MemorySegment to a ByteBuffer, all safety guarantees the MemorySegment implementation makes should continue to hold.
• The MemoryAccessHandles API also adds a set of var handle combinators. This required adding a new IndirectVarHandle subclass of VarHandle. Testing should verify that these new combinators, when used together with the plethora of existing var handle types, work as expected.

Benchmarking

• Since this is a performance sensitive API, benchmarks should be added that compare the performance of memory accesses to that of existing APIs such as Unsafe and ByteBuffer.

Test Inventory

Existing Tests

• Parts of the implementation of ByteBuffer had to be changed to work with MemorySegments. Existing tests for ByteBuffer can be used to verify that they keep functioning as expected.
• The test test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java has been updated to test the spliterator functionality of MemorySegment
• Existing var handle tests in test/jdk/java/lang/invoke/VarHandles were adapted to run in several new configurations that apply trivial/identity adaptation, to test the added var handle combinators and IndirectVarHandle together with all the existing var handle kinds.

New Tests

• New tests have been added in test/jdk/java/foreign to test the new APIs.
• Benchmarks have been added to test/micro/org/openjdk/bench/jdk/incubator/foreign to test the performance of memory accesses, with and without loops.

Test Success Criteria

• At least 80% cyclomatic complexity test coverage
• 100% coverage of the public API
• Memory access performance using the new API should be in the same ball park as that of Unsafe and ByteBuffer