MockVM

[qinsoon]

For testing, we include a DummyVM in the mmtk-core repo. We should rename it to MockVM to properly reflect its usage. And we should allow proper mocking for testing.

[qinsoon]

Here is a list of mock libraries in Rust: https://asomers.github.io/mock_shootout/

With some attempts, here are some of my opinions:

• We need these features from a mocking library (based on the current implementation):
  • mocking associated types
  • mocking static methods in trait
  • mocking generic methods
• We probably need to manually implement mock types. Auto generation of mock types seems fragile and does not cover some edge cases. For example, mockall cannot auto generate mocks for us, due to some unsupported Rust syntaxes.

[qinsoon]

We have gradually added some tests to DummyVM to MMTk core: https://github.com/mmtk/mmtk-core/tree/master/vmbindings/dummyvm/src/tests

We would at some point refactor DummyVM into a proper MockVM. Specifically, we need to be able to define the MockVM's behavior per each test.

For example, currently, when a GC is triggered for a DummyVM, we simply panic.

mmtk-core/vmbindings/dummyvm/src/collection.rs

Line 20 in 0babba2

panic!("block_for_gc is not implemented")

In the test in which we expect a GC to be triggered, we check if the test panics

mmtk-core/vmbindings/dummyvm/src/tests/allocate_with_re_enable_collection.rs

Line 8 in 0babba2

#[should_panic(expected = "block_for_gc is not implemented")]

and in the test in which we expect no GC to be triggered, we simply see if the test passes without panic

mmtk-core/vmbindings/dummyvm/src/tests/allocate_with_disable_collection.rs

Line 8 in 0babba2

pub fn allocate_with_disable_collection() {

The panic behavior of block_for_gc() makes it impossible for us to use the binding for any GC test, as it will panic whenever a GC is triggered. We would expect that MockVM would allow us to define block_for_gc() per each test case.

The simplest approach is to use function pointers. MockVM forwards each call to a separate function pointer, and the function pointer initially points to a default implementation. Each test can create their own function, and update the function pointer for certain API calls.

@wks @KipHamiltons

[wks]

I have another example.

I want my is_mmtk_object feature to work for different VMs. The offsets from the allocated address and the object reference is different among VMs, So I want my test cases to control the behaviour of ObjectModel::object_start_ref of a VM.