Fixing sticky immix #121
Fixing sticky immix #121
Conversation
According to https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore, `+` that appears in the branch name needs to be escaped. Co-authored-by: Eduardo Souza <[email protected]> (cherry picked from commit b40af34)
| obj.as_usize() - std::mem::size_of::<crate::julia_scanning::mmtk_jl_taggedvalue_t>(); | ||
| let t_header = Address::from_usize(as_tagged_value).load::<Address>(); | ||
| let tag = t_header.as_usize() & 3; | ||
| if tag == 2 { |
There was a problem hiding this comment.
I can see from the Julia code, that the write barrier for jl_binding_t sets the bits to 2. It means if jl_binding_t gets modified, the write barrier will set the bits to 2, and we will trace the fields in the jl_binding_t. You probably explained to me earlier why we need to do this, and why we don't need to trace fields in jl_binding_t if it is not in the remset. But I forgot the actual reason.
Can you write it into the comments why we need this code?
There was a problem hiding this comment.
Is the bits cleared in any way? If not, that means once we sets the bits for a jl_binding_t object, the bits stay as 2, and we will trace its fields in every subsequent GCs.
There was a problem hiding this comment.
I can see from the Julia code, that the write barrier for
jl_binding_tsets the bits to 2. It means ifjl_binding_tgets modified, the write barrier will set the bits to 2, and we will trace the fields in thejl_binding_t. You probably explained to me earlier why we need to do this, and why we don't need to trace fields injl_binding_tif it is not in the remset. But I forgot the actual reason.Can you write it into the comments why we need this code?
Oh I see. We don't scan buffers, as they will be scanned as a part of its parent object. But when a jl_binding_t buffer is inserted into remset, they have be to scanned. The gc bits tells us if the buffer is in the remset. Can you put this into comments?
There was a problem hiding this comment.
Is the bits cleared in any way? If not, that means once we sets the bits for a
jl_binding_tobject, the bits stay as 2, and we will trace its fields in every subsequent GCs.
I've added a FIXME for now, but that's true. We should reset the bits after the jl_binding_t object has been scanned.
There was a problem hiding this comment.
Why not just clear the bits after the process_edge calls? Are you worrying that they will cause other issues? If they do (for example, if those bits are used by others for other purposes), it means the implementation is not sound.
|
This PR only affects v1.9.2, not
|
This PR should be merged with mmtk/julia#32.
Copying the description here for simplicity:
This PR adds code for scanning buffers that are Julia bindings that were added in the write barrier.