Let ObjectReference implement Ord

[wks]

This will enable Vec<ObjectReference> to be sorted, and enable ObjectReference to be used as the keys of ordered collections such as BTreeMap. Although mmtk-core currently never sorts Vec<ObjectReference>, developers of mmtk-core as well as bindings may experiment with accessing ObjectReference instances from low addresses to high addresses. It complicates things if ObjectReference does not implement Ord.

[caizixian]

I'm ok with this PR, but I think there's a separate problem we need to rethink. On a conceptual level (which is not the current implenmentation afaik), object references could be some arbitrary handles that is supposed to be opaque to mmtk-core, and you use it by calling the appropriate methods exposed by the VM object model and scanning code. In that sense, the core may or may not be able to depend on the ordering of the handles existing, nor does the ordering always make sense (e.g. if the core starts to depend on the ordering for locality).

[wks]

I'm ok with this PR, but I think there's a separate problem we need to rethink. On a conceptual level (which is not the current implenmentation afaik), object references could be some arbitrary handles that is supposed to be opaque to mmtk-core, and you use it by calling the appropriate methods exposed by the VM object model and scanning code. In that sense, the core may or may not be able to depend on the ordering of the handles existing, nor does the ordering always make sense (e.g. if the core starts to depend on the ordering for locality).

@caizixian We discussed handles before. The conclusion is, if a VM uses indirection tables, and handles are pointers (or indices) of the indirection table entries, then the binding only needs to give MMTk-core the contents of the indirection tables (i.e. the pointer to the object), and allows MMTk-core to update the contents of the indirection tables. The binding doesn't need to give the handles themselves to the MMTk core, and MMTk core shouldn't (and in fact cannot) create handles. So in the end, we define ObjectReference to be a pointer to an object, although it may point to the beginning of an object or an offset from the beginning.

Details can be found in the following Zulip channels:

• About handles: https://mmtk.zulipchat.com/#narrow/stream/262673-mmtk-core/topic/Internal.20reference.20and.20handles
• About creating ObjectReference during GC: https://mmtk.zulipchat.com/#narrow/stream/262673-mmtk-core/topic/Don't.20create.20ObjectReferences.20during.20GC
• More general discussions: https://mmtk.zulipchat.com/#narrow/stream/262673-mmtk-core/topic/object.20reference

[caizixian]

Right. Thanks. I have forgotten. We should collate our design documentation and decisions in one place at some point :)

[qinsoon]

Right. Thanks. I have forgotten. We should collate our design documentation and decisions in one place at some point :)

It is stated in the comments:

mmtk-core/src/util/address.rs

Lines 453 to 457 in f780a11

	/// A runtime may define its "object references" differently. It may define an object reference as
	/// the address of an object, a handle that points to an indirection table entry where a pointer to
	/// the object is held, or anything else. Regardless, MMTk expects each object reference to have a
	/// pointer to the object (an address) in each object reference, and that address should be used
	/// for this `ObjectReference` type.

[qinsoon]

However, I feel it a bit strange to allow ordering on ObjectReference. In what case would object references need to be sorted? In your experiment before, sorting object references did not improvement performance, as the cost of sorting overweighs the benefits of locality. Is there any real need that we know that we want to sort on ObjectReference?

[wks]

However, I feel it a bit strange to allow ordering on ObjectReference. In what case would object references need to be sorted? In your experiment before, sorting object references did not improvement performance, as the cost of sorting overweighs the benefits of locality. Is there any real need that we know that we want to sort on ObjectReference?

I haven't found any case where sorting ObjectReference is definitely beneficial. But experiments are still going on. At this stage, the benefit of letting ObjectReference implement Ord is merely making experiments easier.

[qinsoon]

I didn't realize we have PartialOrd on ObjectReference. If we have PartialOrd, it makes sense to have Ord.

But I would think we should have none on them. The current MMTk core code does not rely on it either. It is not intuitive to compare the order of two object references. We can compare the raw address for object references, something like vec.sort_by(|obj1, obj2| obj1.to_raw_address().cmp(&obj2.to_raw_address())) works well.

[caizixian]

something like vec.sort_by(|obj1, obj2| obj1.to_raw_address().cmp(&obj2.to_raw_address())) works well.

I think one of Kunshan's motivations is to use data structures like BTreeMap. If we don't have ordering, then we limit ourselves to only hashing-based data structures.

[k-sareen]

Yeah but we could order the Addresses instead of ObjectReferences. Address has a definitive order, I'm not sure about ObjectReference given we want to treat them as opaque to MMTk.