Allow IL scanner's dependency graph be GC'd

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.

[MichalStrehovsky]

We don't need to keep the graph in the memory once we're done scanning.

Verified it gets collected now by adding a finalizer to ILScanNodeFactory and having it print something. It didn't get collected previously. If I'm measuring it right, it was rooting about 17 MB of objects in memory on a hello world.

Cc @dotnet/ilc-contrib

[jkotas]

Nice!

[VSadov]

I like the improvement, but I wonder if there is something wrong with the liveness analysis and thus the user needs to do this.
Should we know that the scanner roots are all dead at some point and not report them (at least in release build)?

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

[MichalStrehovsky]

Is it the part that the containing method is 500-lines long that makes it difficult to track when the scanner is unreachable?

I didn't test whether just shuffling things around (without moving scanning into a separate method frame) would be sufficient to get it GC'd. It might have been enough.

JIT is free to extend the lifetimes of things however it sees fit - an extra method frame makes sure the locals really become dead no matter what the JIT decides to do now or in the future.