Kunshan Wang
Kunshan Wang
``` 吾有一數。曰四十二。名之曰「答案」。 ``` 然后，怎么书写“答案”呢？我知道可以这样写： ``` 吾有一術。名之曰「單位函數」。欲行是術。必先得一數。曰「甲」。乃行是術曰。 乃得「甲」。 是謂「單位函數」之術也。 吾有一書。曰四十二。名之曰「答案」。 施「單位函數」於「答案」。書之。 ``` 但像`console.log(x)`这样的，书写一个变量的操作，应该有基本的表达式吧。
This allows the VM to add arbitrary VM-specific allocations into the heap size.
We make the representation of edges VM-specific. The MMTk core only depends on the abstract Edge trait. This allows VM bindings to custom the behaviour of loading/storing of edges, and...
It is a **DRAFT** because: 1. [X] We should rebase it after https://github.com/mmtk/mmtk-core/pull/629 is merged. 2. [ ] Ruby crashes with segmentation fault when using the non-moving Immix. The stack...
The VM may want to provide a different set of default values for MMTk options than those defined in `src/util/options.rs`. For example, - In `mmtk-core`, the default `plan` is `NoGC`,...
# Problem Currently, the `MMTK` instance is usually created statically. The practice of using static singletons is https://github.com/mmtk/mmtk-core/issues/58brought from Java JikesRVM, but this is not idiomatic in Rust. Such practice...
TL;DR: To support edge enqueuing for VMs that use tagged reference, mmtk-core must also be aware of the fact that `ObjectReference` loaded from an edge may not be the address...
TL;DR: There is no common way of processing edges. `ProcessEdgesWork` is not really common. It is only common to full-heap tracing GC. What's worse, the current stack-scanning API (`Scanning::scan_xxxx_root`) depends...
TL;DR: The reference processor is tightly coupled with `ProcessEdgesWork` work packets, making it impossible to support runtimes that can only do object-enqueuing. We can make it general. # Problem Currently,...
In the `Scanning` trait, there are two methods: - `scan_thread_roots` scans **all roots** in **all threads**. - `scan_thread_root` scans **all roots** in **one thread**. The names are confusing because the...