MMTk Callback

[qinsoon]

In GitLab by @u6374399 on Dec 13, 2018, 17:14

For detailed performance measurements, RMMTk needs callbacks.

[qinsoon]

Is this included in #62? If so, we could close this issue.

[caizixian]

https://gitlab.anu.edu.au/mmtk/probes/-/blob/master/probe/MMTkProbe.java

It's partially addressed here https://github.com/mmtk/jikesrvm/blob/67dadebb060ed48687dabf7e30805ee70a810686/rvm/src/org/jikesrvm/mm/mminterface/MemoryManager.java#L184

[caizixian]

Basically we want to expose something for applications to signal Rust MMTk.

[qinsoon]

@caizixian As you referenced, MMTk exposes harness_begin/end(). I assume that is how applications tell MMTk to start/end profiling. I don't quite get what is missing or how we should improve.

[qinsoon]

After some work and discussions, there is the plan for the callbacks/hooks:

1. MMTk should expose these callbacks/hooks to the probe, and those are VM neutral without any VM specific arguments. It means we will remove the parameters, mmtk: &MMTK and tls: OpaquePointer. The probe should be able to directly call those hooks in MMTk.
2. MMTk should provide trait functions that the VM binding can implement and this allows VM to execute VM specific code before or after the harness, such as triggering a GC.

[qinsoon]

Currently we are using a workaround. We keep the Rust API of mmtk-core, which exposes harness_begin(mmtk: &MMTk, tls: OpaquePointer) and harness_end(mmtk: &MMTk), and we add VM-specific code when the binding exposes the C API of harness_begin()/end() (see mmtk/mmtk-jikesrvm#21 and mmtk/mmtk-openjdk#15). This gives us a working implementation and we do not need to prioritise this for now. I am removing this issue from v0.1 milestone.