Fixing sticky immix #32
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
qinsoon
pushed a commit
to mmtk/mmtk-julia
that referenced
this pull request
Jan 29, 2024
This PR should be merged with mmtk/julia#32. Copying the description here for simplicity: > At least one of the issues with sticky immix back ported to [v1.9.2+RAI](https://github.com/mmtk/mmtk-julia/tree/v1.9.2%2BRAI) is that bindings [may occur in the remset](https://github.com/mmtk/julia/blob/c01026c91a3e2e6a064e75e0d4d4cc2f8c0d4c77/src/gc.c#L2417-L2433). However, bindings are currently skipped when scanned by MMTk since they are allocated as buffers. Therefore, we need a way to specify which bindings should actually be scanned since they were added via write barrier. > > Possible sources of problems that haven't been verified yet: > (i) can the `bits.gc` value change after being set by the write barrier? > (ii) should we reset the value after the object has been scanned? This PR adds code for scanning buffers that are Julia bindings that were added in the write barrier.
qinsoon
pushed a commit
to qinsoon/julia
that referenced
this pull request
Jan 31, 2024
Prepend threadid to stacktraces
qinsoon
pushed a commit
to qinsoon/julia
that referenced
this pull request
May 2, 2024
…liaLang#54064) Stdlib: NetworkOptions URL: https://github.com/JuliaLang/NetworkOptions.jl.git Stdlib branch: master Julia branch: master Old commit: aab83e5 New commit: 8eec5cb Julia version: 1.12.0-DEV NetworkOptions version: 1.2.0(Does not match) Bump invoked by: @IanButterworth Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: JuliaLang/NetworkOptions.jl@aab83e5...8eec5cb ``` $ git log --oneline aab83e5..8eec5cb 8eec5cb Hardcode doc edit backlink (mmtk#32) 0bd3345 also reset SYSTEM_CA_ROOTS and ENV_HOST_PATTERN_CACHE from __init__ (mmtk#35) ``` Co-authored-by: Dilum Aluthge <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At least one of the issues with sticky immix back ported to v1.9.2+RAI is that bindings may occur in the remset. However, bindings are currently skipped when scanned by MMTk since they are allocated as buffers. Therefore, we need a way to specify which bindings should actually be scanned since they were added via write barrier.
Possible sources of problems that haven't been verified yet:
(i) can the
bits.gcvalue change after being set by the write barrier?(ii) should we reset the value after the object has been scanned?