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

there seems to be a way to accelerate GC of objects with finalizer #4613

Closed
ygc369 opened this issue Oct 23, 2015 · 11 comments
Closed

there seems to be a way to accelerate GC of objects with finalizer #4613

ygc369 opened this issue Oct 23, 2015 · 11 comments
Assignees
Labels
area-GC-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@ygc369
Copy link

ygc369 commented Oct 23, 2015

When GC of generation 1 or 2 finishes, all garbage objects with finalizer should be moved to heap zone of generation 0. Thus, these objects would be collected next generation 0 GC after their finalizers are called.

@ygc369 ygc369 closed this as completed Oct 23, 2015
@ygc369 ygc369 reopened this Dec 24, 2015
@ygc369
Copy link
Author

ygc369 commented Dec 24, 2015

I think this idea should be considered.

@ygc369
Copy link
Author

ygc369 commented Jun 20, 2016

Nobody is interested in this?

@vancem
Copy link
Contributor

vancem commented Jun 20, 2016

It is very hard to see whether this change would have interesting positive effect on performance. It might, but it might not. Generally speaking we expect finalizable objects to always be a small fraction of the total, and thus any change to improve them is likely to have a very small effect.

Ideas for improvements are considerably more valuable if they have (ideally real world) data that argues that the improvement is very significant.

Note that even with this data, there still is a finite amount of resources. We have not even shipped our V1.0.0 release, so there are many work items that this needs to compete with.

@ygc369 ygc369 closed this as completed Mar 15, 2018
@msftgits msftgits transferred this issue from dotnet/coreclr Jan 30, 2020
@msftgits msftgits added this to the Future milestone Jan 30, 2020
@ygc369
Copy link
Author

ygc369 commented Feb 2, 2020

@vancem
I think that the current behavior is close to a bug, because it delays the reuse of freed memory for no reason. What I proposed should be considered as a way to fix the "bug", not an optimazation.

@ygc369 ygc369 reopened this Feb 2, 2020
@ygc369
Copy link
Author

ygc369 commented Feb 21, 2020

@Maoni0
How do you think about this idea?

@VSadov
Copy link
Member

VSadov commented Mar 23, 2020

Here is how finalization works at the high level:

  • in addition to regular reachability, finalized objects are rooted for finalization purpose.
  • When that root is the last one, the object is added to finalization queue.
  • After finalizer runs the finalization root is severed.
  • If the object is no longer reachable, the next GC will make its space available to new allocations.

There are two metrics that could be improved in the whole scenario - how soon the finalizer runs and how soon the originally occupied space is reclaimed.

Neither of these metrics can be helped by copying the finalized object to Gen0 region.

@VSadov
Copy link
Member

VSadov commented Mar 23, 2020

I do not see how this can work. An example or a prototype could be helpful.
As-is this is not an actionable issue.

@VSadov VSadov closed this as completed Mar 23, 2020
@ygc369
Copy link
Author

ygc369 commented Mar 24, 2020

@VSadov

There are two metrics that could be improved in the whole scenario - how soon the finalizer runs and how soon the originally occupied space is reclaimed.
Neither of these metrics can be helped by copying the finalized object to Gen0 region.

"how soon the originally occupied space is reclaimed"---- I think this metric can be helped by copying the finalized object to Gen0 region, because Gen0 GC always happens before Gen1 or Gen2 GCs.

@VSadov
Copy link
Member

VSadov commented Mar 24, 2020

I think a confusing part is that there is no such thing as "moving" an object. What is possible is to "copy" to a new location and redirect all the references.
To find the references you need to scan the heap. That is too expensive to do for one object.

GC performs such scan for all objects up to a given generation. That makes the cost much lower per-object, but does not make it lower in a whole.

As you see - one way or another a GC (or equivalent amount of work) needs to happen to ensure that the original location is no longer referenced and can be reclaimed/collected.

@ygc369
Copy link
Author

ygc369 commented Mar 24, 2020

@VSadov

To find the references you need to scan the heap. That is too expensive to do for one object.

No, there is no need to scan the heap. Please reread my description:

When GC of generation 1 or 2 finishes, all garbage objects with finalizer should be moved to heap zone of generation 0.

And look at your previous comment:

When that root is the last one, the object is added to finalization queue.

It means that all objects in finalization queue has no other roots, so there is no need to scan the heap to find their references. It is safe to move(or copy) these objects to Gen0 directly. (As these objects might revive after their finalizer is called, the movement need to happen before finalizer runs, I think the movement should happen during GC's compacting period.)

@VSadov
Copy link
Member

VSadov commented Mar 24, 2020

Being not rooted does not imply not being referenced. An object in finalization can and often is still referenced by other objects in the finalization queue or by objects referenced by them indirectly. Any of these objects may become rooted again.

@ghost ghost locked as resolved and limited conversation to collaborators Jan 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-GC-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Projects
None yet
Development

No branches or pull requests

5 participants