-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Comments
I think this idea should be considered. |
Nobody is interested in this? |
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. |
@vancem |
@Maoni0 |
Here is how finalization works at the high level:
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. |
I do not see how this can work. An example or a prototype could be helpful. |
"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. |
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. 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. |
No, there is no need to scan the heap. Please reread my description:
And look at your previous comment:
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.) |
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. |
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.
The text was updated successfully, but these errors were encountered: