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

Is there any roadmap for improving GC? #8098

Closed
ygc369 opened this issue May 13, 2017 · 8 comments
Closed

Is there any roadmap for improving GC? #8098

ygc369 opened this issue May 13, 2017 · 8 comments
Labels
area-GC-coreclr question Answer questions and provide assistance, not an issue with source code or documentation.
Milestone

Comments

@ygc369
Copy link

ygc369 commented May 13, 2017

Are there any new GC algorithms in developing?
Would reference counting collector be an alternative memory management mechanism?

@swgillespie
Copy link
Contributor

Linking threads: dotnet/csharplang#547

@swgillespie
Copy link
Contributor

What advantages do you think are to be had by switching to a reference counting collector instead of improving the GC we already have? Tracing collectors and reference counting collectors are duals of one another, and each has their own tradeoffs.

cc @Maoni0

@ygc369
Copy link
Author

ygc369 commented May 16, 2017

@swgillespie
Except RC and Local GC, what can be done to improve the GC we already have? Is anybody doing this?

@mikedn
Copy link
Contributor

mikedn commented May 16, 2017

what can be done to improve the GC we already have?

But what exactly do you want to improve about GC?

You keep creating all this GC related issues but you never provide any sort of details - use cases, expectations, numbers, anything - and thus not exactly constructive.

@ygc369
Copy link
Author

ygc369 commented May 16, 2017

@mikedn
I'm sorry. But my mother tongue is not English. It is not easy for me to write a long English article with many details. I can only describe my ideas and I think their advantages are obvious and do not need more explainations.

@mikedn
Copy link
Contributor

mikedn commented May 16, 2017

I think their advantages are obvious and do not need more explainations

Nope, there is nothing obvious about the advantages of reference counting.

@jkotas
Copy link
Member

jkotas commented May 16, 2017

There have been thousands of research papers written about garbage collection, many of them on reference counting. We are aware of all the key ideas that have been published to date. There are folks in Microsoft Research working in this space too. It is very easy to pick and recommend an (existing) idea. The very hard part is how to incorporate it to the system to make it work better for significant fraction of important scenarios.

It is well established that simple reference counting does not work well because of the high cost of the reference count maintenance and inability to collect cycles. There are modifications that try to address it, but nothing obviously better accross the board.

http://gchandbook.org/ is a great summary of different garbage collection ideas with discussion of its process and cons. I would recommend that you to read this book, and try to implement and measure one or two ideas from this book to get a feel for how memory management works in practice before submitting more suggestions here. If you are not able to get access to the book where you live, send me email to my Microsoft address and we will figure out how to get you one.

@jkotas
Copy link
Member

jkotas commented May 16, 2017

Duplicate of dotnet/csharplang#547 and #4029

@jkotas jkotas closed this as completed May 16, 2017
@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-GC-coreclr question Answer questions and provide assistance, not an issue with source code or documentation.
Projects
None yet
Development

No branches or pull requests

5 participants