Support for object pinning

[udesou]

This is a draft PR to support object pinning.
I have added three methods to the SFT: pin_object, unpin_object, and is_object_pinned.
In policies where pinning should not be supported I've created a panic message. For policies where objects do not move, all methods simply return false and do nothing. I'm not 100% if objects can be pinned in mark compact, so I left these methods as unimplemented() for now.
The PR also adds a PinningBitSpec to the object model, and check to the trace_object_with_opportunistic_copy function before attempting to forward objects or clear the forwarding status.

[wenyuzhao]

LGTM. Just minor questions

[qinsoon]

I think we would need to discuss about the new API methods. Currently there are pin, unpin and is_pinned. The problem is that for a non-moving space, is_pinned will return true (which means the object is pinned) even if every call to pin returns false (which means we fail to pin the object). If necessary, we can define semantics like this. But generally, it is a bit confusing. I suggest we have some discussion first.

[qinsoon]

@udesou Can you fix the tests? Then we can get this merged, and #706 will not include changes about pinning.

[qinsoon]

LGTM

[wks]

I just discovered a small problem. Variable names with an underscore in front of it, such as _object, indicates that they are unused. The compiler will not give the "unused variables" warning for those variables. We should remove those underscores since we started using them.

[udesou]

I just discovered a small problem. Variable names with an underscore in front of it, such as _object, indicates that they are unused. The compiler will not give the "unused variables" warning for those variables. We should remove those underscores since we started using them.

Where exactly do you mean they should be renamed? Is it in code like:

    #[inline(always)]
    fn is_pinned(&self, _object: ObjectReference) -> bool {
        #[cfg(feature = "object_pinning")]
        return self.is_object_pinned(_object);

        #[cfg(not(feature = "object_pinning"))]
        false
    }

If so, I was just using the same idea as

    fn initialize_object_metadata(&self, _object: ObjectReference, _alloc: bool) {
        #[cfg(feature = "global_alloc_bit")]
        crate::util::alloc_bit::set_alloc_bit::<VM>(_object);
    }

[qinsoon]

I just discovered a small problem. Variable names with an underscore in front of it, such as _object, indicates that they are unused. The compiler will not give the "unused variables" warning for those variables. We should remove those underscores since we started using them.

Where exactly do you mean they should be renamed? Is it in code like:

    #[inline(always)]
    fn is_pinned(&self, _object: ObjectReference) -> bool {
        #[cfg(feature = "object_pinning")]
        return self.is_object_pinned(_object);

        #[cfg(not(feature = "object_pinning"))]
        false
    }

If so, I was just using the same idea as

    fn initialize_object_metadata(&self, _object: ObjectReference, _alloc: bool) {
        #[cfg(feature = "global_alloc_bit")]
        crate::util::alloc_bit::set_alloc_bit::<VM>(_object);
    }

The issue is how we tell Rust about arguments that are only used under some features and are unused in other cases. What we currently do for most of the cases are: leaving the argument with the underscore _ prefix, and use it if you need to.

You could argue that the best approach is to separate the implementations, such as

     #[cfg(feature = "object_pinning")]
     fn is_pinned(&self, object: ObjectReference) -> bool {
         self.is_object_pinned(object)
     }
     #[cfg(not(feature = "object_pinning"))]
     fn is_pinned(&self, object: ObjectReference) -> bool {
         false
     }

However, this may not be desirable in some cases when there are code shared.

Anyway, I think this is a minor styling issue. What has been done in this PR is consistent with our current code base, and I don't feel it is wrong -- it is just one approach to deal with it.

[wks]

OK. I didn't realise that the Rust compiler is not considering it as "used" when only used in some configuration.

LGTM now.