Merge the jdk-21.0.9+3-mmtk branch into master #335
Conversation
Wenyu says we don't do class unloading. This is fine.
OpenJDK 21 no longer has `REF_OTHER` in the enumeration type `ReferenceType`.
This makes it easier to debug
The MMTkHeap instance will receive calls to `object_iterate` when connected from VisualVM and panic. Leaving this function blank will not properly implement the iteration, but will allow the VM to be profiled with VisualVM.
The super class method `BarrierSet::on_thread_attach` now does initializations related to nmethods, particularly the "nmethod disarmed guard value".
This commit addresses minor issues after merging the SATB barrier and the barrier refactoring to the OpenJDK 21 binding. In x86 barrier assembler, we use `testptr` for testing if a register is zero. OpenJDK 21 now gives 3 tmp registers to assemblers. We use them instead. We also removed the workaround for OpenJDK 11 where the given `tmp1` and `tmp2` registers overlap with operand registers. We updated `MMTkSATBBarrierSetC2::load_at_resolved` by copying some code from `G1BarrierSetC2`.
We revert to our old repository and directory name `openjdk` instead of
`jdk`.
- The upstream OpenJDK project creates one repository for every major
release, such as `jdk21u`, and updates to that major versions are
pushed into that repository. The `jdk` repository is for the main
line development. Since our `openjdk` repo actually follows update
repos (such as `jdk21u`), it doesn't make sense to use `jdk` as the
repository name.
- There are many other JVM implementations out there, such as JikesRVM
and OpenJ9. Using the repository name `openjdk` emphasizes that it
is OpenJDK.
|
Would it be cleaner if we rename |
This approach has the advantage that each branch maps uniquely to an But there is an obvious disadvantage. We may switch the default OpenJDK branch from time to time, such as from Another disadvantage is that we will need to change the mmtk-core CI every time we make this change, even if the CI scripts in the new branch is 100% compatible with the mmtk-core CI scripts. So I suggest we still keep one unique Another advantage of keeping the |
We could have different default branches for each JDK version, like
I don't see this as a disadvantage. We can easily change what branch mmtk-core tests with: https://github.com/mmtk/mmtk-core/blob/e25ad8bb969f5d650de3f1946582075923bafcc9/.github/workflows/pr-binding-refs.yml#L125 Explicitly switching to a different branch is not a bad idea.
Consider this scenario: someone is using |
|
My intuition is that this pull request does not really look like a normal pull request. So maybe it should not be a pull request, and we should consider other approaches to get the changes. I am happy to discuss more on this. |
This sounds good to me, too. We can use
OK. It's OK as long as it is easy to do so.
Yes. This is indeed a concern. But to support multiple parallel branches like I think one way to solve it is to update
Git also has a feature called "symbolic refs". As suggested in this page, we can use it to make aliases of branches. We can make an actual |
One way to make the transition is to keep an explicit
We should probably discuss this in our next meeting. |
The benchmark name defined in base.yml is simply "dacapochopin", and we reference that in normal-heap.yml that. We also mention the MR2 version of the DaCapo Chopin JAR file wherever appropriate.
|
Kunshan and I discussed more on this. There are a few things we agreed on:
We haven't agreed on whether we should keep using I am favoring deprecating Kunshan favors keeping @wks If I missed any point from our discussion, just add to this thread. |
I feel this is okay to me if:
|
|
@qinsoon has summarized what we discussed today. I'll clarify, in terms of Git commit graph, what will happen after we make the transition This is the current status.
The figure below is the state right after merging. Before merging, we will create a branch
The figure below is the state in the future. Major development efforts will be on We will also have a We will also have a
|
|
Here is a summary of some opposing ideas. Do people stick to a particular JDK version, or do they move to the newest JDK version?
Do we use GitHub's default branch to point to the active branch, or do we have a
Note that we can have both versioned branches such as |
We merge the branch for OpenJDK 21 into
master. From now on, themasterbranch of themmtk-openjdkrepository will directly target OpenJDK 21. Thejdk-21.0.9+3-mmtkbranch will be decommissioned, and will remain its current state (i.e. the state just before merging intomaster), and will only be looked up when any developers are interested in the history of the development of the OpenJDK binding.The following things work:
mmtk-openjdkbinding work.mmtk-corerepo work.One important thing that doesn't work immediately is the performance regression CI. It requires a change in the
ci-perf-kitrepo and also needs related changes in the CI scripts inmmtk-core. This PR is for OpenJDK, and will not trigger the performance regression CI. This leaves us a small window to updatemmtk-coreandci-perf-kitafter this PR is merged.This PR should not be merged with "squash merge". Instead we should make a proper merge commit so that the
jdk-21.0.9+3-mmtkbranch will be considered as an ancestor of themasterbranch from Git's point of view. GitHub will also consider the branchjdk-21.0.9+3-mmtkas "merged".Major changes compared to the OpenJDK 11 binding
We made the following changes in the mmtk-openjdk repo:
-normalpart from the OpenJDK CONF string.