Yi Lin
Yi Lin
MMTk currently triggers GCs based on a fixed heap size. ~~We have plans to support dynamic heap size (e.g. https://github.com/mmtk/mmtk-core/issues/561), and we wlll have different GC triggering implementations in that...
This PR adds build info to mmtk-core, including mmtk-core version, git hash, and features. `built` is used to collect those information. This closes https://github.com/mmtk/mmtk-core/issues/634. * use Rust build script to...
I think one of them is used for a given binding based on their constants in `Scanning`. From the document, it is unclear which one will be used. We need...
This pull request adds an SFT map implementation for 64 bits systems, which maps one MMTk space to an entry in the SFT map. This closes https://github.com/mmtk/mmtk-core/issues/219 and closes https://github.com/mmtk/mmtk-core/issues/531....
For breaking changes in mmtk-core, we always make sure that the bindings we maintain work with the new changes. To achieve this, we will need to have pull requests in...
In GitLab by @qinsoon on Jan 26, 2020, 11:44 A lot of structs in Rust MMTk are initialized with some uninitialized fields. We are using empty values (such as `0`,...
We should provide a version string for MMTk core, and each binding (possibly including the VM version as well).
Since 9a3ebff00d006388fb6369dd7c78a9b2cb74f647, the mutator performance CI always timed out. I need to look into this.
Currently `SFTMap` is a dense table (`Vec`), which each entry maps to a chunk. This works fine if our heap range is dense. As we plan to use sparse heap...
We track performance for all of our commits (e.g. https://www.mmtk.io/ci-perf-result/master/openjdk_semispace_history.html). However, we may have some bogus runs that were recorded and plotted in the graph. This PR along with the...