You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Oh, checkmark. For one-word pointer objects, we store the checkmark in the type bit. That means that, at the beginning of checkmark, the type bits of all one-word objects are set to "scalar", even though they're all pointers. For most objects this is fine, since we'll "mark" them before scanning them, which will set one-word objects to "pointer". However, for objects with finalizers, we scan the object without marking it. If the object isn't otherwise reachable, nothing will have set its checkmark, so scanobject will see it as a "scalar" word and not follow it.
This is such an obscure combination of circumstances that I'm not worried about fixing it for now. But there are a few ways to fix it. We could teach scanobject that one word objects are always a pointer, though that would potentially slow down an extremely hot code path for almost no gain. We could put the checkmark in the live/dead bit now that it's free. Or we could pull the checkmark out of the heap bitmap entirely (I already have a CL to do this locally).
Oh, checkmark. For one-word pointer objects, we store the checkmark in the type bit. That means that, at the beginning of checkmark, the type bits of all one-word objects are set to "scalar", even though they're all pointers. For most objects this is fine, since we'll "mark" them before scanning them, which will set one-word objects to "pointer". However, for objects with finalizers, we scan the object without marking it. If the object isn't otherwise reachable, nothing will have set its checkmark, so scanobject will see it as a "scalar" word and not follow it.
This is such an obscure combination of circumstances that I'm not worried about fixing it for now. But there are a few ways to fix it. We could teach scanobject that one word objects are always a pointer, though that would potentially slow down an extremely hot code path for almost no gain. We could put the checkmark in the live/dead bit now that it's free. Or we could pull the checkmark out of the heap bitmap entirely (I already have a CL to do this locally).
/cc @RLH
The text was updated successfully, but these errors were encountered: