Kunshan Wang

I fixed one obvious bug which is a typo that removes the barrier when the new field value is null. https://github.com/mmtk/mmtk-openjdk/pull/332/commits/940c6915a8d39661cb78112afc97ef4b80cb1305 But the SIGSEGV bug remains. It is not related...

I can't reproduce the bug with `-XX:-UseCompressedOops`. Maybe it is related to compressed pointer.

After updating mmtk-core to revision https://github.com/mmtk/mmtk-core/commit/1ffa5b325a07d4fe99fe7e7008b295f8febea407 (PR https://github.com/mmtk/mmtk-core/pull/1400), I can't reproduce the crash. It was still reproducible before that commit. I don't understand it. OpenJDK doesn't use `alloc_with_options` at all.

I managed to reproduce the crash on the master branch. It seems to be more reproducible if we disable C2. *(update: I created an issue for this: https://github.com/mmtk/mmtk-openjdk/issues/334, and it...

The bug https://github.com/mmtk/mmtk-openjdk/issues/334 has been fixed, and this PR no longer crashes when running `h2o`.

After reading the source code of OpenJDK, I think we don't need to exactly copy what OpenJDK is doing. For example, we may organize discovered references in vectors instead of...

I wonder whether we can hack `BarrierResolver::resolve_barrier_gc()` in openjdk so that is when it is `ThirdPartyHeapBarrierSet`, we delegate the selection of barrier function to a method of the active `ThirdPartyHeap`...

Here are some more clues. The PR https://github.com/mmtk/mmtk-core/pull/1400 accidentally made all GCs of ConcurrentImmix full GC, and it hid the bug so that it won't crash. After fixing (https://github.com/mmtk/mmtk-core/pull/1404), it...

Now I am certain that the concurrent GC is reclaiming live objects. The following patch clears the body of all objects in ImmixSpace that are not marked during `Block::sweep` using...

Due to a bug which will be fixed by https://github.com/mmtk/mmtk-core/pull/1412, no objects in the LOS has unlog bits set during concurrent marking, so the SATB barrier is not applied to...