-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Negate find_object GetConservativeGC logic. #39905
Conversation
Tagging subscribers to this area: @dotnet/gc |
@@ -18090,7 +18090,7 @@ uint8_t* gc_heap::find_object (uint8_t* interior) | |||
heap_segment* seg = find_segment (interior, FALSE); | |||
if (seg | |||
#ifdef FEATURE_CONSERVATIVE_GC | |||
&& (GCConfig::GetConservativeGC() || interior <= heap_segment_allocated(seg)) | |||
&& (!GCConfig::GetConservativeGC() || interior <= heap_segment_allocated(seg)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this effects the path we take here in the default CoreCLR config. CoreCLR has FEATURE_CONSERVATIVE_GC
defined and GCConfig::GetConservativeGC
defaults to false.
It means that this was effectively if (seg && interior <= heap_segment_allocated(seg))
before this change in the default CoreCLR config, and it is just if (seg)
after this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these checks for GetConservativeGC
seem suspicious to me - I dunno who added them but the impl seems questionable... the idea, if I had to guess, was probably that if we are in conservative mode (ie the config is set), we can tolerate an interior pointer that's > heap_segment_allocated but all we do is we return 0 there - the only case where we could return a non zero value is if an interior pointer is >= heap_segment_mem and < heap_segment_allocated, regardless of whether the conservative config is set. so the code should just be
if (seg && (interior < heap_segment_allocated(seg))
{
and the assert can be deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we want to be more complete, we could do
#ifdef FEATURE_CONSERVATIVE_GC
if (interior >= heap_segment_allocated (seg))
return 0;
#else
assert (interior < heap_segment_allocated (seg));
#endif
meaning that if we find a valid seg for it, we tolerate it if conservative config is set and inteiror is > heap_segment_allocated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comments. I believe I have updated as per the last comment. I tried the Wasm Generics test in a loop 100 times and it completed without errors, so this fix looks good for CoreRT/Wasm. I'm sure you experts will advise if I have it wrong.
src/coreclr/src/gc/gc.cpp
Outdated
#else | ||
assert (interior < heap_segment_allocated (seg)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#else | |
assert (interior < heap_segment_allocated (seg)); |
The exact same assert is repeated unconditionally a few lines below. I would delete it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, removed.
@yowl Thank you! |
This PR implements the suggested fix at dotnet/corert#8205 that solves an assert that is hit when testing the Wasm backend of CoreRT and is required to fix the related issue dotnet/corert#8210.
Fixes: dotnet/corert#8210
Closes: dotnet/corert#8205