`find_object_from_internal_pointer` is not usable during object tracing

[qinsoon]

The current implementation of find_object_from_internal_pointer finds the VO bit that is set at or before the given internal pointer, gets the object size of the object (where the VO bit is set), then checks if the internal pointer is actually within the object memory.

In order to get the object size, we need to access the object metadata, assuming the object includes valid metadata.

In the case of an object being copied, we could either keep the VO bit for the from object, or clear it. However, if we keep the VO bit, the from object is already dead, and may not have valid metadata for us to get its size. If we clear the VO bit, then we cannot find the base reference if the object is moved. In either case, we cannot use find_object_from_internal_pointer for an internal pointer to an object that has been moved.

[qinsoon]

There could be two solutions:

1. If the binding needs to use find_object_from_internal_pointer, they need to make sure that we can access metadata and object size for forwarded objects (the from object). For example, storing the forwarding pointer should not overwrite metadata, and the binding should not clear any metadata that is used to access object size. However, this is impossible for the current Julia binding (the current Julia binding needs to access Julia's object header and object payload to calculate the object size).
2. MMTk core provides another version of find_object_from_internal_pointer that the user needs to guarantee that the argument is known to be an internal pointer, thus we only need to find the VO bit and do not need to check the object size.

[wks]

storing the forwarding pointer should not overwrite metadata, and the binding should not clear any metadata that is used to access object size

If the forwarding pointer is already written, the object must have already been copied. In this case, we just follow the forwarding pointer and read the header in the to-object. They should have the same size.

There is a risk, however, that if one GC worker attempts to read the object while another GC worker is forwarding that object. We may use the remaining bit pattern of the forwarding bits to "lock" the object, temporarily preventing it from being forwarded. This may introduce a run-time overhead every time we call find_object_from_internal_pointer.

[wks]

Another solution is that when writing the forwarding pointer, we also write the size of the object next to the forwarding pointer. In this way, we don't need the object body to know its size.

Preferably, we write the new size at the object header word so that we can use one atomic word loading to load the header, and use bit testing to test if the object is already forwarded or not. If already forwarded, the header should already contain its size.

• forwarding not triggered yet: | 0 | 0 | header | payload1 | payload2 | payload3 | ... |
• being forwarded: | 0 | 1 | header | payload1 | payload2 | payload3 | ... |
• forwarded: | 1 | 1 | object size | forwarding pointer | payload2 | payload3 | ... |

[qinsoon]

If the forwarding pointer is already written, the object must have already been copied. In this case, we just follow the forwarding pointer and read the header in the to-object. They should have the same size.

The size may not be the same, e.g. address-based hashing.

Another solution is that when writing the forwarding pointer, we also write the size of the object next to the forwarding pointer. In this way, we don't need the object body to know its size.

This means the min object size needs to be at least two words and we need to check if an object is forwarded in find_object_from_internal_pointer before invoking ObjectModel::get_current_size. Both seem fine.

[qinsoon]

MMTk core provides another version of find_object_from_internal_pointer that the user needs to guarantee that the argument is known to be an internal pointer, thus we only need to find the VO bit and do not need to check the object size.

This is still my preferred approach. If the object scanning is precise, then we will know for sure that a pointer is an internal pointer, and whatever we find with VO bit should be the base pointer -- we do not need to check the size. This scenario is different from encountering a possible internal pointer during conservative stack scanning where we are not sure if the given value is a pointer or an internal pointer or not.

[wks]

There is a risk, however, that if one GC worker attempts to read the object while another GC worker is forwarding that object. We may use the remaining bit pattern of the forwarding bits to "lock" the object, temporarily preventing it from being forwarded. This may introduce a run-time overhead every time we call find_object_from_internal_pointer.

Update: Another solution is to read the one-word object header atomically. If the forwarding pointer has the same location as the header, and another GC worker may forward that object concurrently, then the current GC worker thread either

1. reads the old value of the header, i.e. the actual header, or
2. reads the new value at that location, i.e. the forwarding pointer.

In case (1), we still have the full information of the object, and we can still work out the object size.

In case (2), it means the forwarding has completed. We go to the to-space object, and compute the object size there. We need to compensate for the effect of address-based hashing if we need to.

[qinsoon]

We discussed this today.

We can introduce another version of the function where the user guarantees the pointer is an internal pointer, thus MMTk core does not need to check object size.
However, if a binding needs conservatism during object tracing, they will have to deal with forwarded objects in the object size function in the binding side, using Kunshan's proposal above.

This should be documented in the code as well.