Wenyu Zhao

@steveblackburn suggested we should escalate this. All storage other than the Java heap should be involved when accounting heap size, including rust/malloc objects, side-metadata and OpenJDK's MetaSpace.

Any progress on this PR? I'd love to see the macro crate can actually support no_std.

Yeah I'd love to take over the job and at least fix #106

> @wenyuzhao can you confirm the current implementation is what you had in mind? > > https://github.com/mmtk/mmtk-core/blob/a058b8c4f3dbfa625823847bb5df8e5c87f44e34/src/scheduler/stat.rs#L46 > > I'm reopening this until you confirm. The `WorkerLocalStat` solved most of...

Not sure what's the problem. But our CI did not catch this.

This is what's happening: https://github.com/mmtk/mmtk-openjdk/blob/master/mmtk/src/object_scanning.rs#L121 ```rust impl OopIterate for InstanceRefKlass { fn oop_iterate(&self, oop: Oop, closure: &mut impl EdgeVisitor) { ... match self.instance_klass.reference_type { ... ReferenceType::Soft => add_soft_candidate(reference), ... ReferenceType::Final...

The weak processing on JikesRVM and OpenJDK is different. For JikesRVM, here are the steps of soft processing: 1. Build a list of ALL soft-refs in the heap during the...

So for openjdk, we need to (1) disable `allow_new_candidate` before weak processing (2) during weak processing, treat all references as strong. (2) is still a problem. When `allow_new_candidate` is set...

@qinsoon is it possible to trigger a benchmark github action here? like the ones we did to the mmtk-core PRs?

Hi @kk2049, thanks for reporting the error. I can confirm that the error exists even with the latest MMTk. Our OpenJDK binding does not yet fully support some interfaces, e.g.,...