Remove NULL ObjectReference

[wks]

We changed ObjectReference so that it is backed by NonZeroUsize, and can no longer represent a NULL reference. For cases where an ObjectReferences may or may not exist, Option<ObjectReference> should be used instead.

This is an API-breaking change.

• ObjectReference::NULL and ObjectReference::is_null() are removed.
• ObjectReference::from_raw_address() now returns Option<ObjectReference>. The unsafe method ObjectReference::from_raw_address_unchecked() assumes the address is not zero, and returns ObjectReference.
• API functions that may or may not return a valid ObjectReference now return Option<ObjectReference>. Examples include Edge::load() and ReferenceGlue::get_referent().

If a VM binding needs to expose Option<ObjectReference> to native (C/C++) programs, a convenient type crate::util::api_util::NullableObjectReference is provided.

Fixes: https://github.com/mmtk/mmtk-core/issues/1043

[wks]

Here are some preliminary benchmark results. Two builds:

• build1: master
• build2: this PR + the mmtk-openjdk counterpart (https://github.com/mmtk/mmtk-openjdk/pull/265)

lusearch from DaCapo Chopin, 40 invocations, 5 iterations, 2.5x and 3x min heap size, ran on shrew.moma (Coffee Lake) and vole.moma (Ryzen 4).

I ran it with Immix and GenCopy. However GenCopy overflowed the phase counter. As a result, the stats of subsequent GCs are discarded from the result. (See https://github.com/mmtk/mmtk-core/issues/1074) So I am only showing the results for Immix.

https://squirrel.anu.edu.au/plotty/wks/noproject/#0|shrew-2024-01-19-Fri-080239^shrew-2024-01-19-Fri-113438^vole-2024-01-19-Fri-080218^vole-2024-01-19-Fri-113411&benchmark^build^hfac^invocation^iteration^logfile^mmtk_gc&GC^time^time.other^time.stw&|10&iteration^1^4&mmtk_gc^1^Immix|20&1^invocation|30&1&benchmark^hfac^logfile&build;build1|60&hfac&logfile|70&hfac-logfile^shrew-vole-253x|40&Histogram%20(with%20CI)^build^hfac-logfile&

From the data, the impact on total time is between -0.5% to +0.5%, and the error bar is large. Interestingly, it always shows slowdown on shrew, and always speed-up on vole. For STW time, "shrew 2.5x" has a slow-down of 1%, and "vole 3x" has a speed-up of 1.5%, but their error bars are too large.

I think the result of forcing ObjectReference to be non-zero is insignificant for lusearch with Immix.

[wks]

More benchmark results. I ran the same binary on shrew.moma and mole.moma (identical to vole.moma), 20 invocations, 3x min heap size, using Immix and StickyImmix GC.

Plotty link: https://squirrel.anu.edu.au/plotty/wks/noproject/#0|mole-2024-01-20-Sat-113636^shrew-2024-01-20-Sat-113610&benchmark^build^invocation^iteration^logfile^mmtk_gc&GC^time^time.other^time.stw&|10&iteration^1^4|20&1^invocation|30&1&benchmark^logfile^mmtk_gc&build;build1|60&build&logfile&mmtk_gc|70&build-logfile-mmtk_gc^blg-2024-01-22|41&Histogram%20(with%20CI)^build-logfile-mmtk_gc^benchmark&

Total time: normalized to build1 of the corresponding machine-plan pair:

For each machine-plan pair, the geomean of total time of build2 is between 99.6% to 100.3% of that of build1.

Other time:

Geomeans are between 99.8% to 100.3% of build1.

STW time:

STW times are between 97.9% to 101.0% of build1. But given the noise level, it is hard to conclude there is any improvement. We can see significant speed-up for build2-shrew-StickyImmix for biojava, jython and pmd, but build2-mole-StickyImmix does not have the same speed-up for those benchmarks. This is a bit hard to explain.

[wks]

binding-refs OPENJDK_BINDING_REPO=wks/mmtk-openjdk OPENJDK_BINDING_REF=fix/no-null-objref JIKESRVM_BINDING_REPO=wks/mmtk-jikesrvm JIKESRVM_BINDING_REF=fix/no-null-objref V8_BINDING_REPO=wks/mmtk-v8 V8_BINDING_REF=fix/no-null-objref RUBY_BINDING_REPO=wks/mmtk-ruby RUBY_BINDING_REF=fix/no-null-objref JULIA_BINDING_REPO=wks/mmtk-julia JULIA_BINDING_REF=fix/no-null-objref

[wks]

This PR is now ready for review. Associated PRs for the bindings:

• https://github.com/mmtk/mmtk-openjdk/pull/265
• https://github.com/mmtk/mmtk-jikesrvm/pull/169
• https://github.com/mmtk/mmtk-v8/pull/84
• https://github.com/mmtk/mmtk-ruby/pull/62
• https://github.com/mmtk/mmtk-julia/pull/146

[wks]

Also a quick check: is there any change that may affect performance for OpenJDK and MMTk since the evaluation in #1064 (comment)?

I don't think so, but I'll re-run the benchmarks just to be safe.

[wks]

I re-ran the benchmarks with the same setting as in https://github.com/mmtk/mmtk-core/pull/1064#issuecomment-1903158498

Plotty: https://squirrel.anu.edu.au/plotty/wks/noproject/#0|shrew-2024-04-26-Fri-091850^mole-2024-04-26-Fri-091914&benchmark^build^invocation^iteration^logfile^mmtk_gc&GC^time^time.other^time.stw&|10&iteration^1^4|20&1^invocation|30&1&benchmark^logfile^mmtk_gc&build;build1|60&build&mmtk_gc&logfile|70&build-mmtk_gc-logfile^mole-shrew-20240426|40&Histogram%20(with%20CI)^build-mmtk_gc-logfile^benchmark&

Total time: (geomens of build2 are between 99.5% to 100.2% of build1, varying among plan * machine pairs)

Other time: (99.6% to 100.1%)

STW time: (99.2% to 100.8%)

The differences are within 1%. This result is consistent with the last evaluation.