Report -1 for GC.GetGeneration(nongc_obj) and same for GetObjectGeneration #85017

EgorBo · 2023-04-18T22:58:34Z

First contribution to dotnet/diagnostics#4156

Report -1 as a generation for nongc objects (also referred as "frozen objects') via GC.GetGeneration API and same for profiler API ICorProfilerInfo2::GetObjectGeneration

…ation

ghost · 2023-04-18T22:58:44Z

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

First contribution to dotnet/diagnostics#4156

Report -1 as a generation for nongc objects (also referred as "frozen objects') via GC.GetGeneration API and same for profiler API ICorProfilerInfo2::GetObjectGeneration

Author:	EgorBo
Assignees:	-
Labels:	`area-Diagnostics-coreclr`
Milestone:	-

src/coreclr/pal/prebuilt/corerror/mscorurt.rc

jkotas · 2023-04-18T23:43:50Z

src/coreclr/vm/proftoeeinterfaceimpl.cpp

+        range->rangeStart = 0;
+        range->rangeLength = 0;
+        range->rangeLengthReserved = 0;
+        return CORPROF_E_NOT_GC_OBJECT;


Returning error here makes this more breaking than necessary. Why can't we just return S_OK?

cc @noahfalk

Returning -1 seemed like it was going to be a breaking change no matter what so I figured we may as well make it more obvious rather than try to minimize it and increase risk that tools break more subtly. However we don't yet have feedback from profiler authors one way or another and this behavior is just a best guess on my part. If you think we'd be better off defaulting to keeping S_OK @jkotas I don't have a strong opinion on it.

Traditionally (in textbook sense) GC generations imply that genX can be collected without collecting generations X+.

-1 makes impression that any level of GC will collect frozen, while in fact it is the opposite - any generation can be collected without touching frozen.

That seems to imply that frozen objects logically belong to generation > MAX_GEN.
Perhaps 3 or MAXINT could work better that -1 ?

If you think we'd be better off defaulting to keeping S_OK

It looks odd to me to return failure error code and still try to return meaningful values. I see that there are other profiler APIs that work like that, so it should be fine to return error code. You can ignore my feedback.

I kind of agree with @VSadov that e.g. INT_MAX value would be safer, e.g. I already had to apply a hack in code because GC/VM usages of WhichGeneration participate in comparisons so -1 will trigger a different path than previously max_generation did. Although, this is a part of the plan to make this breaking change more visible so 🤷

Perhaps 3 or MAXINT could work better that -1

I have no particular preference between MAXINT and -1. I don't anticipate its going to make a difference myself but I also have no concern changing it. 3 I would not use - in the right context 3 is used as a legitimate generation number and the goal is that nobody should treat this value as if it is a generation.

There are not that many purposes for WhichGeneration other than to answer questions like “can this object be collected before that one?” or “will this object survive GC X?”.

Assigning immortal objects to gen -1 feels like not the most convenient/intuitive.

I tried INT_MAX and there was only one place that I had to change (some NativeAOT test expecting frozen objects to be in Gen2). Also, GC.Collect(GC.GetGeneration.. is not breaking now as Jan highlighted.
For -1 it becomes a little bit more complicated.

So any strong opinions for keeping -1 ?

I think INT_MAX is the correct value. Even with unforeseen future changes, I do not see anything collecting less often than frozen.

jkotas · 2023-04-18T23:45:50Z

We may need to file a breaking change notice for this. The code out there may not be expecting invalid generation ID to be returned from GetGeneration. For example, consider code like this https://github.com/HUKUTAXVIII/TankGame/blob/4366c4f99b2ed2667bab68c72d377c2e086f15e3/TankGame/Game.cs#L241

jkotas · 2023-04-18T23:48:23Z

src/coreclr/vm/proftoeeinterfaceimpl.cpp

+    if (hp->IsInFrozenSegment((Object*)objectId))
+    {
+        range->generation = (COR_PRF_GC_GENERATION)-1;
+        range->rangeStart = 0;


We can return memory range for the given frozen segments here.

We can return memory range for the given frozen segments here.

I agree, but I thought that the idea was to not provide support for apis with explicit GC prefix/name/suffix for nongc objects (cc @noahfalk)

Right, the plan of record is to avoid treating Non-GC objects as if they are on the GC heap, and that also included not treating the non-GC segments as if they are some type of special GC generation. We could smuggle the range here at the cost of blurring the lines and potentially creating some confusion. If profiler vendors said it would be specifically helpful to them I don't think it bends the rules too badly though. From the limited profiler feedback I've heard so far folks wanted to enumerate the Non-GC region boundaries directly and resolve the pointers themsevles offline.

I'm expecting @davmason to broadcast the changes we are doing to profiler vendors and then depending on their feedback we can make adjustments.

noahfalk · 2023-04-19T00:20:47Z

We may need to file a breaking change notice for this

Yeah, its certainly a breaking change.

src/coreclr/gc/gcinterface.h

noahfalk · 2023-04-19T13:36:24Z

@davmason

EgorBo · 2023-04-19T18:48:25Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-19T18:48:41Z

Azure Pipelines successfully started running 1 pipeline(s).

EgorBo · 2023-04-19T20:05:31Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-19T20:05:47Z

Azure Pipelines successfully started running 1 pipeline(s).

EgorBo · 2023-04-19T21:57:12Z

It's ready for review I guess then if we're fine with INT_MAX

EgorBo · 2023-04-19T23:27:21Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-19T23:27:37Z

Azure Pipelines successfully started running 1 pipeline(s).

EgorBo · 2023-04-20T12:04:40Z

Failure is #85081

EgorBo · 2023-04-20T12:07:51Z

@davmason @noahfalk PTAL, I have more changes for the profiler but they rely on this (tests)

noahfalk

Looked fine to me, but we should get @Maoni0 and @davmason to review the GC and profiler parts respectively. Thanks @EgorBo!

noahfalk · 2023-04-20T17:50:45Z

src/coreclr/gc/gc.cpp

+        // For regions those are never in-range.
+        return INT32_MAX;
+    }
+#endif


@Maoni0 - heads up, you probably want to look at any changes that touch the GC.

I'm fine with INT32_MAX as the value that the profiling API returns back to 3rd party code in GetGenerationBounds but I leave it to you to decide if that is also an acceptable behavior for this GC code to have.

noahfalk · 2023-04-20T18:16:36Z

src/tests/profiler/gc/nongcheap.cs

+            if (gen != int.MaxValue)
+                throw new Exception("object is expected to be in a non-gc heaps");
+
+            GC.Collect(gen);


The current docs for GC.Collect() and GC.MaxGeneration states:

Use the MaxGeneration property to determine the maximum value you can specify when calling the Collect(Int32) method that takes a generation parameter.

I don't think we need to promise anyone that GC.Collect(int.MaxValue) will work even if it happens to do so in the current implementation. Instead I think we would document something like:

When GC.GetGeneration() is called with an object that doesn't exist on the GC heap, these objects do not have any associated GC generation. GetGeneration() will return int.MaxValue in this case and this value should not be treated as a valid GC generation for any other GC API that needs a generation specified.

We should only call GC.Collect(Int32.MaxValue) in the test if we consider it a contract and are willing to fix it if it breaks. If we decide to not view that as a contract we shouldn't have it in the test

GC.Collect(Int32.MaxValue) always worked fine. Changing it would be a breaking change.

I do not think the test coverage for it belongs to this test. A better place to add a test coverage for it would be https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime/tests/System/GCTests.cs .

Move to GCTests.cs, thanks!

Changing it would be a breaking change

In case there was any confusion I was not proposing we change GC.Collect() behavior. I wanted to avoid declaring in our docs that GC.Collect(int.MaxValue) was supported and well-defined.

davmason

Other than the one comment around GC.Collect it looks good to me

ghost · 2023-04-20T23:26:03Z

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

EgorBo · 2023-04-21T16:03:13Z

Leaving open for @dotnet/gc to sign off the gc changes

Maoni0 · 2023-04-21T19:23:20Z

I'll be looking at this this afternoon. thanks for your patience!

Maoni0 · 2023-04-21T23:28:13Z

I see there are quite a few comments related to whether to return -1 or INT32_MAX so I'll just respond here.

I would actually prefer to return -1 to indicate "this object is simply not managed by the GC". the rule of "if an object's generation is smaller than another object's, it will be collected before that other object" is only applicable for objects managed by the GC so you should not apply it to objects not managed by the GC. -1 is so distinct and serves this purpose well.

however, the GC interface between GC and VM uses unsigned int and changing that can change the behavior in VM. there's actually not that many places in the VM that call WhichGeneration - based on a cursory look (at the 8.0 src) it should not cause anything breaking but I'd rather not risk it (we have to worry about clrgc.dll working with previous version of coreclr. dll. it'd be trivial if we just needed it to work with 8.0+).

so return INT32_MAX is the safer choice and I think we should go with that. thanks for all the discussions!

Maoni0

LGTM. thanks so much for making these changes!

cshung · 2023-04-22T04:15:16Z

src/tests/profiler/gc/nongcheap.cs

+        [MethodImpl(MethodImplOptions.NoInlining)]
+        static void AllocateNonGcHeapObjects()
+        {
+            // When this method is invoked, JIT is expected to trigger allocations for these


This might not work for ReadyToRun?

Thanks, disabled the test for crossgen

I do not think that this is correct. Did you see the test actually failing with crossgen?

If I am reading the code correctly, this test should work with crossgen just fine. The string literals referenced by R2R code must be allocated on frozen heap. Otherwise, the tiering from R2R to Tier1 would work poorly - the tiering would be stuck with non-frozen string literals.

Thanks, you're absolutely right

src/tests/profiler/native/nongcheap/nongcheap.cpp

cshung · 2023-04-22T04:22:43Z

src/tests/profiler/native/nongcheap/nongcheap.cpp

+    // non-GC objects (same for GC.GetGeneration() API) have generation = -1
+    if (gen.generation == (COR_PRF_GC_GENERATION)INT32_MAX)
+    {
+        if (!FAILED(hr))


How about calling this API to verify that it is a frozen object as well?

From my understanding we sort of ignore these old Frozen* profiler APIs as we re-branded Frozen as NonGC. For the same reason we introduce a new API to traverse frozen objects and ignore existing EnumModuleFrozenObjects

Ignore is probably fine when we were still designing, but it is really lousy from a testing perspective. It should either supposed to work or it doesn't. If it is supposed to work, and we are not testing it, it would be a test hole. If it is not supposed to work, then we should update the code to make it fails. If we wanted to depreciate old APIs in favor of new ones, we should make that clear in the documentation. Either way, something is missing.

EgorBo · 2023-04-23T11:48:21Z

@noahfalk @jkotas do I still need to file the breaking change ticket since we no longer return -1? Also, do we use the same mechanism for breaking changes in the profiler or we just notify the consumers directly?

jkotas · 2023-04-23T14:34:41Z

do I still need to file the breaking change ticket since we no longer return -1?

Yes, this falls under "Disallowed - Increasing the range of returned values for a property, field, return or out value" from https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-rules.md#behavioral-changes

The process is documented at https://github.com/dotnet/runtime/blob/main/docs/project/breaking-change-process.md#process

EgorBo · 2023-04-23T14:57:33Z

do I still need to file the breaking change ticket since we no longer return -1?

Yes, this falls under "Disallowed - Increasing the range of returned values for a property, field, return or out value" from https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-rules.md#behavioral-changes

The process is documented at https://github.com/dotnet/runtime/blob/main/docs/project/breaking-change-process.md#process

Thanks, filed dotnet/docs#35105
Build failure is unrelated: #84101

Merging to unblock #85100

Report -1 for GC.GetGeneration(nongc_obj) and same for GetObjectGener…

0ac29ee

…ation

dotnet-issue-labeler bot added the area-Diagnostics-coreclr label Apr 18, 2023

ghost assigned EgorBo Apr 18, 2023

EgorBo commented Apr 18, 2023

View reviewed changes

src/coreclr/pal/prebuilt/corerror/mscorurt.rc Outdated Show resolved Hide resolved

EgorBo added 2 commits April 19, 2023 01:07

Update corerror.xml

71f63b2

revert changes in error codes

c3754e0

jkotas reviewed Apr 18, 2023

View reviewed changes

build-analysis bot mentioned this pull request Apr 19, 2023

IOException running NuGet-Migrations during tests in dotnet CLI first run #80619

Closed

EgorBo added 2 commits April 19, 2023 11:34

Test commit

d1268e5

Merge branch 'main' of github.com:dotnet/runtime into nongc-generation

8072970

build-analysis bot mentioned this pull request Apr 19, 2023

Tracking issue for CI build timeouts #76454

Closed

fix CI

d57e193

jkotas reviewed Apr 19, 2023

View reviewed changes

src/coreclr/gc/gcinterface.h Outdated Show resolved Hide resolved

EgorBo added 2 commits April 19, 2023 20:09

try INT_MAX

8720b4f

revert unrelated change

0e422ab

EgorBo marked this pull request as ready for review April 19, 2023 18:47

oops

330f22a

Update nongcheap.cs

d63b652

This was referenced Apr 20, 2023

Could not load file or assembly 'Microsoft.CodeAnalysis.NetAnalyzers #84995

Closed

[wasm] interpreter timeouts when WebSocket closes unexpectedly #84101

Closed

EgorBo mentioned this pull request Apr 20, 2023

Implement ICorProfilerInfo14::EnumerateNonGCObjects #85100

Merged

jkotas mentioned this pull request Aug 14, 2023

Diagnostic support for NonGC heap dotnet/diagnostics#4156

Open

21 tasks

noahfalk approved these changes Apr 20, 2023

View reviewed changes

davmason approved these changes Apr 20, 2023

View reviewed changes

EgorBo added the breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. label Apr 20, 2023

ghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 20, 2023

EgorBo added 2 commits April 21, 2023 14:16

Address feedback

2135544

Add asserts

b50f36a

Maoni0 approved these changes Apr 21, 2023

View reviewed changes

cshung approved these changes Apr 22, 2023

View reviewed changes

Don't run the test with crossgen

2ce1588

build-analysis bot mentioned this pull request Apr 23, 2023

Build on Windows Fails sometimes with fatal error C1090: PDB API call failed #48070

Open

Update nongcheap.csproj

fdcfbdd

EgorBo merged commit 2c9e483 into dotnet:main Apr 23, 2023
153 of 156 checks passed

EgorBo deleted the nongc-generation branch April 23, 2023 15:00

ghost locked as resolved and limited conversation to collaborators May 25, 2023

ericstj added this to the 8.0.0 milestone Jun 28, 2023

EgorBo removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Oct 19, 2023

Report -1 for GC.GetGeneration(nongc_obj) and same for GetObjectGeneration #85017

Report -1 for GC.GetGeneration(nongc_obj) and same for GetObjectGeneration #85017

Conversation

EgorBo commented Apr 18, 2023

ghost commented Apr 18, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VSadov Apr 19, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EgorBo Apr 19, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VSadov Apr 19, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VSadov Apr 19, 2023 • edited

Choose a reason for hiding this comment

jkotas commented Apr 18, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noahfalk commented Apr 19, 2023

noahfalk commented Apr 19, 2023

EgorBo commented Apr 19, 2023

azure-pipelines bot commented Apr 19, 2023

EgorBo commented Apr 19, 2023

azure-pipelines bot commented Apr 19, 2023

EgorBo commented Apr 19, 2023

EgorBo commented Apr 19, 2023

azure-pipelines bot commented Apr 19, 2023

EgorBo commented Apr 20, 2023

EgorBo commented Apr 20, 2023

noahfalk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davmason left a comment

Choose a reason for hiding this comment

ghost commented Apr 20, 2023 • edited by EgorBo

EgorBo commented Apr 21, 2023

Maoni0 commented Apr 21, 2023

Maoni0 commented Apr 21, 2023

Maoni0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EgorBo Apr 22, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EgorBo commented Apr 23, 2023

jkotas commented Apr 23, 2023

EgorBo commented Apr 23, 2023 • edited

VSadov Apr 19, 2023 •

edited

EgorBo Apr 19, 2023 •

edited

VSadov Apr 19, 2023 •

edited

VSadov Apr 19, 2023 •

edited

jkotas commented Apr 18, 2023 •

edited

ghost commented Apr 20, 2023 •

edited by EgorBo

EgorBo Apr 22, 2023 •

edited

EgorBo commented Apr 23, 2023 •

edited