{"id":15069498,"url":"https://github.com/mmtk/mmtk-openjdk","last_synced_at":"2026-02-10T05:02:08.390Z","repository":{"id":36982963,"uuid":"249876414","full_name":"mmtk/mmtk-openjdk","owner":"mmtk","description":"OpenJDK binding for MMTk","archived":false,"fork":false,"pushed_at":"2025-04-30T01:53:04.000Z","size":777,"stargazers_count":34,"open_issues_count":47,"forks_count":39,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-05-09T00:06:24.810Z","etag":null,"topics":["java","mmtk","openjdk","vm"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mmtk.png","metadata":{"files":{"readme":"README-legacy.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE-APACHE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-03-25T03:18:07.000Z","updated_at":"2025-04-29T23:01:25.000Z","dependencies_parsed_at":"2024-01-17T10:35:24.680Z","dependency_job_id":"7d9564e7-c7f9-4f70-be0b-3548a793c4d8","html_url":"https://github.com/mmtk/mmtk-openjdk","commit_stats":null,"previous_names":[],"tags_count":31,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmtk%2Fmmtk-openjdk","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmtk%2Fmmtk-openjdk/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmtk%2Fmmtk-openjdk/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmtk%2Fmmtk-openjdk/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mmtk","download_url":"https://codeload.github.com/mmtk/mmtk-openjdk/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253166518,"owners_count":21864476,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["java","mmtk","openjdk","vm"],"created_at":"2024-09-25T01:42:52.807Z","updated_at":"2026-02-10T05:02:02.967Z","avatar_url":"https://github.com/mmtk.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"## Progress Summary:\r\n\r\n### Introduced a runtime argument -XX:+UseMMTk :  \r\nWe are on the way to complete building an interface between the JVM and the rust-mmtk. We are calling it `MMTkHeap`. It is enabled by a command line argument `-XX:+UseMMTk`. make, javac, and java (when this argument is not given) work the same way as before. Only difference is that we have to run an `export` command for every new terminal that intends to execute `make`, `javac`, or `java`.\r\n\r\n### Partially implemented BarrierSet and CollectedHeap for MMTk:\r\nCurrently `MMTkHeap` tries to `allocate` from rust-mmtk, but there are some unimplemented methods from its superclass, so core dump occurs. We created a `BarrierSet` named `NoBarrier`. We modified several CPU level methods to introduce `NoBarrier` there. There are several classes which require support from rust-mmtk. After the support is added, the implementations of those classes can be completed.\r\n\r\n### Testing our work:\r\nThe latest commit (**Commit 1b48c800** in mmtk branch) is a buildable and runnable version. We are attaching a [document](./Testing_Openjdk_MMTk_Branch.md) that has instructions to test our code.\r\n\r\n\r\n## In Details:\r\n\r\n### Warm-up and environment setup:\r\nThe first several weeks we had to spend some time to explore the *openjdk-10* codebase. We had explored openjdk-8 previously, but back then we didn't have any intention to make such big changes. However, we found a build procedure with rust-mmtk integrated very soon, thanks to Pavel and Isaac.\r\n\r\n### First attempt to allocate with rust-mmtk:\r\nAt first we tested injecting the allocation codes into the existing system. It was able to allocate using rust-mmtk allocator. But `make` and `javac` also need memory allocation. As it replaced the default allocator, it created some conflicts with the build process of openjdk. We knew that we would need a runtime parameter to select mmtk allocator.\r\n\r\n### Runtime argument for enabling MMTk:\r\nEarlier in January, we introduced a runtime parameter to enable rust-mmtk allocator. At first it was running the built-in Parallel GC behind the scene. The best part of this parameter is that a user will not feel existence of our work unless they add this argument from command line. `make` and `javac` work as they did before. So does `java` unless we add `-XX:+UseMMTk` argument from command line.\r\n\r\n### Implementing MMTkHeap as a subclass of ParallelScavengeHeap:\r\nJVM needs a data structure named `CollectedHeap` to work properly. Every garbage collector has an instance of this data structure. `CollectedHeap` has some pure abstract methods. So its subclasses need to implement some methods. For example, Parallel GC uses `ParallelScavengeHeap` that extends this class.\r\n\r\nSo we wanted to create an abstraction of a Heap that would communicate with rust-mmtk. We named it `MMTkHeap`. For the beginning phase we created a class named `MMTkHeap` that extended `ParallelScavengeHeap`. We intended to override the necessary components.\r\nAs it had some components of `ParallelScavengeHeap`, it created some conflicts when the VM didn't find what it expected. For example, there are methods like *`block_size`*, *`amount_of_space_used`* etc. When we replaced the allocator with rust-mmtk allocator, some of them were not functioning properly. We discussed it with **Rifat**, our advisor in Bangladesh. He suggested to create `MMTkHeap` without any dependence on any other GC.\r\n\r\n### Partial implementation of independent MMTkHeap and NoBarrier:\r\nTherefore, we have made `MMTkHeap` a direct subclass of `CollectedHeap`. As a result we are left with a bunch of *pure abstract methods*. There were also some issue related to barriers. We created a class `NoBarrier` and introduced it to the CPU level methods which perform barrier related tasks before and after memory accesses. However, currently the `NoBarrier` is supported on *JVM for x86 processors only*. Later we will need to add this support for other processors as well.\r\n\r\n### Why MMTkHeap, NoBarrier, and MMTkMemoryPool?:\r\nDirectly quoted form [http://openjdk.java.net/jeps/304](http://openjdk.java.net/jeps/304)\r\n\u003eMore specifically, a garbage collector implementation will have to provide:  \r\n■\tThe heap, a subclass of CollectedHeap  \r\n■\tThe barrier set, a subclass of BarrierSet, which implements the various barriers for the runtime  \r\n■\tAn implementation of CollectorPolicy  \r\n■\tAn implementation of GCInterpreterSupport, which implements the various barriers for a GC for the interpreter (using assembler instructions)  \r\n■\tAn implementation of GCC1Support, which implements the various barriers for a GC for the C1 compiler  \r\n■\tAn implementation of GCC2Support, which implements the various barriers for a GC for the C2 compiler  \r\n■\tInitialization of eventual GC specific arguments  \r\n■\tSetup of a MemoryService, the related memory pools, memory managers, etc. ”\r\n\r\nIn simple words, the VM has significant dependence on several GC related classes. We will need to implement abstractions of a `CollectedHeap`, `MemoryPool`, `BarrierSet`, and some other classes to connect rust-mmtk with the JVM. But the actual GC related tasks will be handled by rust-mmtk.\r\n\r\n## Issues Ahead:\r\nWe think the following tasks will be necessary:\r\n- Complete implementation of `MMTkHeap`\r\n- Complete implementation of `NoBarrier`\r\n- Complete implementation of `MMTkMemoryPool`\r\n- `NoBarrier` support for all processors\r\n\r\n\r\nWe need some support from Rust-MMTK.  Pavel told us that he would look into it. Our vm requires some attributes of the heap at runtime through some abstract methods specified in `ColectedHeap`.  These methods are called by JVM and Universe.  Currently we believe our vm crashes due to these lackings.\r\n \r\n\r\n__Allocation Requirements:__  \r\n\r\n    char* _base;  \r\n    size_t _size;  \r\n    size_t Used_bytes  \r\n    size_t max_capacity (It is the total_space - capacity_of_to_space in Semispace )  \r\n    size_t _noaccess_prefix;  \r\n    size_t _alignment;  \r\n    bool   executable;  \r\n    int    _fd_for_heap;  //File descriptor for the heap.We will provide this to Rust-MMTK.\r\n\r\n__GC Requirements:__  (when GC is completed in Rust)  \r\n\r\n    Last_gc_time  \r\n\r\nSome other things may be required.  We will know for sure when we start incorporating it.  \r\nWhen Pavel gives us methods to access these attributes we can proceed to the garbage collection part. \r\n\r\n__Making facilities for GC:__  \r\nPavel told us we need to provide the following two things for GC.\r\n\r\n__1.Finding Roots :__  \r\nFor roots, we have made a plan with Rifat.  We will follow the way psMarkSweep does it. We will incorporate it after allocation gets bug free.  We have gone through the codes extensively to understand how this works.  We  will simply recreate what it does.\r\n\r\nWhat it does is it pushes all its roots in a stack called `marking_stack`.  We will do something similar and pass the data structure. \r\n\r\n\r\n__2.Specifying which class members are pointers:__  \r\nWe will go through the class OOP for solving this.  This class is for handling objects and holds object attributes.  We have not started working for it yet.  Rifat told us to look into it after allocation is successful.\r\n\r\n---\r\n*Thank You*\r\n\u003e*--Abdullah Al Mamun  \r\n and --Tanveer Hannan*","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmmtk%2Fmmtk-openjdk","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmmtk%2Fmmtk-openjdk","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmmtk%2Fmmtk-openjdk/lists"}