-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Simplify sweeping of big values #54936
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Marking as draft until the x64 failure is investigated. |
8020759
to
a271d93
Compare
Btw, since you are changing this code, is the linked list an efficient enough data structure for this? I haven't measured the overhead of sweeping through this so I'm not sure but it's potentially a place where we spent some time pointer chasing. |
1b7041f
to
3ad2b27
Compare
Probably? Note that the sweeping code will need to access the GC bits in |
f1c762c
to
64b1fe4
Compare
c5b9e75
to
4b333ab
Compare
Latest commit looks fine from a GC time perspective:
|
4b333ab
to
1d67c6f
Compare
ca573db
to
2ad22b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. Some more comments would be great.
9ac935c
to
66fe70a
Compare
Co-authored-by: Kiran Pamnany <kpamnany@users.noreply.github.com>
66fe70a
to
31ccd72
Compare
They should have been deleted in #54936, but were not.
Simplifies the layout of the doubly linked list of big objects to make it a bit more canonical: let's just store a pointer to the previous element, instead of storing a "pointer to the next element of the previous element". This should make the implementation a bit easier to understand without incurring any memory overhead. I ran the serial and multithreaded benchmarks from GCBenchmarks and this seems fairly close to performance neutral on my machine. We also ran our internal benchmarks on it at RAI and it looks fine from a correctness and performance point of view. --------- Co-authored-by: Kiran Pamnany <kpamnany@users.noreply.github.com>
They should have been deleted in JuliaLang#54936, but were not.
Simplifies the layout of the doubly linked list of big objects to make it a bit more canonical: let's just store a pointer to the previous element, instead of storing a "pointer to the next element of the previous element". This should make the implementation a bit easier to understand without incurring any memory overhead. I ran the serial and multithreaded benchmarks from GCBenchmarks and this seems fairly close to performance neutral on my machine. We also ran our internal benchmarks on it at RAI and it looks fine from a correctness and performance point of view. --------- Co-authored-by: Kiran Pamnany <kpamnany@users.noreply.github.com>
They should have been deleted in JuliaLang#54936, but were not.
Simplifies the layout of the doubly linked list of big objects to make it a bit more canonical: let's just store a pointer to the previous element, instead of storing a "pointer to the next element of the previous element". This should make the implementation a bit easier to understand without incurring any memory overhead. I ran the serial and multithreaded benchmarks from GCBenchmarks and this seems fairly close to performance neutral on my machine. We also ran our internal benchmarks on it at RAI and it looks fine from a correctness and performance point of view. --------- Co-authored-by: Kiran Pamnany <kpamnany@users.noreply.github.com>
They should have been deleted in JuliaLang#54936, but were not.
Simplifies the layout of the doubly linked list of big objects to make it a bit more canonical: let's just store a pointer to the previous element, instead of storing a "pointer to the next element of the previous element". This should make the implementation a bit easier to understand without incurring any memory overhead.
I ran the serial and multithreaded benchmarks from GCBenchmarks and this seems fairly close to performance neutral on my machine. We also ran our internal benchmarks on it at RAI and it looks fine from a correctness and performance point of view.