|
| 1 | +## Progress Summary: |
| 2 | + |
| 3 | +### Introduced a runtime argument -XX:+UseMMTk : |
| 4 | +We 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`. |
| 5 | + |
| 6 | +### Partially implemented BarrierSet and CollectedHeap for MMTk: |
| 7 | +Currently `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. |
| 8 | + |
| 9 | +### Testing our work: |
| 10 | +The 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. |
| 11 | + |
| 12 | + |
| 13 | +## In Details: |
| 14 | + |
| 15 | +### Warm-up and environment setup: |
| 16 | +The 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. |
| 17 | + |
| 18 | +### First attempt to allocate with rust-mmtk: |
| 19 | +At 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. |
| 20 | + |
| 21 | +### Runtime argument for enabling MMTk: |
| 22 | +Earlier 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. |
| 23 | + |
| 24 | +### Implementing MMTkHeap as a subclass of ParallelScavengeHeap: |
| 25 | +JVM 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. |
| 26 | + |
| 27 | +So 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. |
| 28 | +As 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. |
| 29 | + |
| 30 | +### Partial implementation of independent MMTkHeap and NoBarrier: |
| 31 | +Therefore, 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. |
| 32 | + |
| 33 | +### Why MMTkHeap, NoBarrier, and MMTkMemoryPool?: |
| 34 | +Directly quoted form [http://openjdk.java.net/jeps/304](http://openjdk.java.net/jeps/304) |
| 35 | +>More specifically, a garbage collector implementation will have to provide: |
| 36 | +■ The heap, a subclass of CollectedHeap |
| 37 | +■ The barrier set, a subclass of BarrierSet, which implements the various barriers for the runtime |
| 38 | +■ An implementation of CollectorPolicy |
| 39 | +■ An implementation of GCInterpreterSupport, which implements the various barriers for a GC for the interpreter (using assembler instructions) |
| 40 | +■ An implementation of GCC1Support, which implements the various barriers for a GC for the C1 compiler |
| 41 | +■ An implementation of GCC2Support, which implements the various barriers for a GC for the C2 compiler |
| 42 | +■ Initialization of eventual GC specific arguments |
| 43 | +■ Setup of a MemoryService, the related memory pools, memory managers, etc. ” |
| 44 | + |
| 45 | +In 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. |
| 46 | + |
| 47 | +## Issues Ahead: |
| 48 | +We think the following tasks will be necessary: |
| 49 | +- Complete implementation of `MMTkHeap` |
| 50 | +- Complete implementation of `NoBarrier` |
| 51 | +- Complete implementation of `MMTkMemoryPool` |
| 52 | +- `NoBarrier` support for all processors |
| 53 | + |
| 54 | + |
| 55 | +We 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. |
| 56 | + |
| 57 | + |
| 58 | +__Allocation Requirements:__ |
| 59 | + |
| 60 | + char* _base; |
| 61 | + size_t _size; |
| 62 | + size_t Used_bytes |
| 63 | + size_t max_capacity (It is the total_space - capacity_of_to_space in Semispace ) |
| 64 | + size_t _noaccess_prefix; |
| 65 | + size_t _alignment; |
| 66 | + bool executable; |
| 67 | + int _fd_for_heap; //File descriptor for the heap.We will provide this to Rust-MMTK. |
| 68 | + |
| 69 | +__GC Requirements:__ (when GC is completed in Rust) |
| 70 | + |
| 71 | + Last_gc_time |
| 72 | + |
| 73 | +Some other things may be required. We will know for sure when we start incorporating it. |
| 74 | +When Pavel gives us methods to access these attributes we can proceed to the garbage collection part. |
| 75 | + |
| 76 | +__Making facilities for GC:__ |
| 77 | +Pavel told us we need to provide the following two things for GC. |
| 78 | + |
| 79 | +__1.Finding Roots :__ |
| 80 | +For 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. |
| 81 | + |
| 82 | +What it does is it pushes all its roots in a stack called `marking_stack`. We will do something similar and pass the data structure. |
| 83 | + |
| 84 | + |
| 85 | +__2.Specifying which class members are pointers:__ |
| 86 | +We 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. |
| 87 | + |
| 88 | +--- |
| 89 | +*Thank You* |
| 90 | +>*--Abdullah Al Mamun |
| 91 | + and --Tanveer Hannan* |
0 commit comments