Skip to content
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

Access AtomicReference as a delegated property #69

Closed
saket opened this issue Sep 16, 2021 · 4 comments
Closed

Access AtomicReference as a delegated property #69

saket opened this issue Sep 16, 2021 · 4 comments

Comments

@saket
Copy link

saket commented Sep 16, 2021

Hey folks, would you be interested in letting AtomicReference be accessed using a delegate? It'll simplify usage by a bit by avoiding the additional get/set calls. I can send a PR if this sounds good to you.

operator fun <T> AtomicReference<T>.getValue(thisObj: Any?, property: KProperty<*>): T = get()
operator fun <T> AtomicReference<T>.setValue(thisObj: Any?, property: KProperty<*>, value: T) = set(value)

Before:

val reference = AtomicReference("foo")
reference.value = "bar"   // or set()
println(reference.value)  // or get()

After:

var reference by AtomicReference("foo")
reference = "bar"
println(reference)

I'm also thinking that this'll reduce the amount of changes needed to migrate away from AtomicReferences in codebases once kotlin native's new memory model becomes stable.

@kpgalligan
Copy link
Contributor

We did something like this a while ago. I think the reason I was reluctant to include it was because of the memory leak issue. Because of that, you should null out your AtomicReference instances to allow the GC to collect them (which is arguably one of the reasons they're redoing the memory model, at least according to what I've read).

The end result being, if you're using AtomicReference, you should make it nullable and zero those values out. I think that's what kind of stopped us from going down this path in Stately. However, it's useful, so if you want to add it, I think we'll take it!

@saket
Copy link
Author

saket commented Sep 27, 2021

Because of that, you should null out your AtomicReference instances to allow the GC to collect them

TIL. I had no idea about this. Will have to go through my codebase and check for usages.

if you're using AtomicReference, you should make it nullable and zero those values out. I think that's what kind of stopped us from going down this path in Stately.

Does offering delegate extensions for AtomicReference block people from doing this in any way?

@saket
Copy link
Author

saket commented Nov 16, 2021

Bumping this again for visibility

@volo-droid
Copy link

Because of that, you should null out your AtomicReference instances to allow the GC to collect them (which is arguably one of the reasons they're redoing the memory model, at least according to what I've read).

@kpgalligan is it still the case with the new memory model?

@saket saket closed this as completed Jun 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants