In some cases, the generation of living objects after GC should not be increased

[ygc369]

1. Sometimes we may want to call GC.collect() to collect garbage at once but do not want to increase generation of living objects after GC. A new parameter should be added to GC.collect() to indicate whether to increase generation of living objects after GC.

2. If living objects after GC are only referenced by local variables on stack, their generation should not be increased too. Because they are likely to become garbage soon.

[ayende]

It would also be nice to get some information about the result of the GC
run (how much was freed, etc).

*Hibernating Rhinos Ltd *

Oren Eini* l CEO l *Mobile: + 972-52-548-6969

Office: +972-4-622-7811 *l *Fax: +972-153-4-622-7811

On Fri, Oct 23, 2015 at 6:40 AM, ygc369 notifications@github.com wrote:

If living objects after normal GC(not manually caused) are only referenced
by local variables on stack, their generation should not be increased too.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/coreclr/issues/1855#issuecomment-150452498.

[ygc369]

Nobody is interested in this?

[ygc369]

Any progress about this issue?

[sharwell]

@ygc369 Do you have more information about use cases for this? Currently I would disagree with this statement:

Sometimes we may want to call GC.Collect()

And if you disagree with that statement, then the rest of the feature becomes unnecessary. It would be very helpful to understand:

1. Why would one want to call GC.Collect(), as opposed to simply not calling GC.Collect()?
2. Under conditions of the first answer, when and how would this proposal benefit the application?

[sharwell]

@ygc369 You don't have to close this issue if you feel strongly it should be changed. But considering how substantial of a change this would be, it's good to be able to explain how it would benefit you in practice. 😄

[ygc369]

@sharwell
OK.
I give up the first situation. What do you think about the second situation?

If living objects after GC are only referenced by local variables on stack, their generation should not be increased too. Because they are likely to become garbage soon.

Besides this issue, I have another issue about generation GC: https://github.com/dotnet/coreclr/issues/1856

[swgillespie]

@ygc369 Do you have any data that could back up that claim? It sounds dubious to me. Particularly with a program like this:

public class Repro
{
    public static void Allocate()
    {
        object[] onStack = new object[1024];
        LoopForever();
    }

    public static void LoopForever() { while(true) {} }
}

[ygc369]

@sharwell
Both this issue (the second situation) and dotnet/coreclr#1856 have obvious benefit of performance. They would make GC more timely.

[ygc369]

@swgillespie
In your example, the function Allocate will never return. Such functions are usually the entrance function of a thread or task, for example the main function. I admit that I ignored this situation, so I will close this issue and let's discuss dotnet/coreclr#1856.