Update to MMTk core PR #817

[qinsoon]

Update for mmtk/mmtk-core#817.

[wks]

Obviously this PR is a quick hack to adapt to the new API. Although we can make it more idiomatic in a subsequent PR, I prefer we do it now, because implementing the API in an idiomatic way can help us check if this API is properly designed. If we find it difficult to implement the OpenJDKMutatorIterator by wrapping a JavaThreadIteratorWithHandle (for example, due to lifetime issues), we may need to adjust the signature of the ActivePlan::mutators() method.

[wks]

Guarding the global iterator instance (static MaybeUninit<JavaThreadIteratorWithHandle> jtiwh;) in C++ is one way to adapt to the new API. It is as correct as the previous code.

But given that OpenJDK provides a proper iterator type JavaThreadIteratorWithHandle, I think a more straightforward way to implement OpenJDKMutatorIterator is wrapping an instance of JavaThreadIteratorWithHandle (or a smart pointer to it) right into the OpenJDKMutatorIterator itself.

[qinsoon]

Done. I removed the global iterator, and moved that to each iterator. JavaThreadIteratorWithHandle is a StackObj, thus cannot be allocated in the heap. I create an uninitialized instance in Rust, and pass that to C++ to let it initialize the instance.

[wks]

The obvious problem is that the Rust code now knows the layout of the C++ struct JavaThreadIteratorWithHandle. This makes the code much less maintainable, especially if the layout changes in unspecified ways at different debug levels (and the Rust code must match the C++-side debug level).

From the code, I found that the Thread class has pointers back to some internal structures of JavaThreadIteratorWithHandle (see comments). This prevents us from instantiating JavaThreadIteratorWithHandle on the stack and then copying it to the Rust Iterator. I also tried working around this by using the placement new syntax to initialise JavaThreadIteratorWithHandle in a pre-allocated buffer, but it failed too. It looks like StackObj also prevented placement new by defining private new methods.

Perhaps the safest way is still switching to internal iteration.

[wks]

This step moves the constructed JavaThreadIteratorWithHandle instance to another location.

However, part of the race-prevention algorithm in OpenJDK includes letting each Thread hold a pointer to the SafeThreadsListPtr instance inside JavaThreadIteratorWithHandle. If the SafeThreadsListPtr is moved, the field in Thread becomes a dangling pointer.

See

• https://github.com/mmtk/openjdk/blob/e1e420b3c4fd627218e45ec977972561c559acec/src/hotspot/share/runtime/threadSMR.cpp#LL381C13-L381C13
• https://github.com/mmtk/openjdk/blob/e1e420b3c4fd627218e45ec977972561c559acec/src/hotspot/share/runtime/threadSMR.cpp#L416

[wks]

There is one missing upcall: the destructor. JavaThreadIteratorWithHandle has a destructor which should be called when the iterator is dropped.

[wks]

Maybe the easiest solution is just collecting the mutator pointers in a Vec and embed the Vec into the Iterator<Mutator>.

The following is the typical use case in mmtk-core:

        for mutator in <C::VM as VMBinding>::VMActivePlan::mutators() {
            mmtk.scheduler.work_buckets[WorkBucketStage::Prepare]
                .add(PrepareMutator::<C::VM>::new(mutator));
        }

It creates one work packet for each mutator. This means we assume the mutator pointer to be valid during the GC anyway, even after the iterator returned by mutators() returned. Under such assumption, it should be safe to just collect the mutator pointers.

[qinsoon]

Closed, in favor of #220.