Uh oh!
There was an error while loading. Please reload this page.
Fix building unboxing and real generic method targets at the same time - #129729
Conversation
When a single type load needs both an unboxing and non-unboxing entrypoint at the same time, we'd build the same generic dictionary twice and fail during registration. The surgical fix is to allow type loader to do the work twice, but stop at the point where we would try to allocate it. Runtime type loader having unboxing MethodDescs was a mistake. This is not a problem if we don't need both at the same time since the all the lookups for existing dictionary already ignore the unboxing bit. (Which is why we fail during registration in the bug - unboxing bit is not part of the key.) No regression test because the test is in dotnet#128702.
Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib |
There was a problem hiding this comment.
Pull request overview
This PR updates the NativeAOT runtime type loader’s dynamic generic method dictionary handling to avoid double-building / double-registering the same generic dictionary when both unboxing and non-unboxing entrypoints are needed during a single type build.
Changes:
- Filters dynamic generic method registration to avoid registering both unboxing + non-unboxing variants when they share the same runtime method dictionary.
- Changes dictionary allocation order to allocate non-unboxing method dictionaries first, then either associate unboxing methods with the existing dictionary or allocate only when needed.
- Skips finishing dictionaries for unboxing methods that were associated with an already-allocated non-unboxing dictionary.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
MichalStrehovsky
commented
Jun 23, 2026
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
davidwrighton
left a comment
There was a problem hiding this comment.
Ok, that's officially obscure. But it looks like a decent fix given that the problem is extremely rare.
MichalStrehovsky
commented
Jun 24, 2026
/ba-g arm64 windows is known broken because the timeout is getting forced too low. macos is #125933. |
Uh oh!
There was an error while loading. Please reload this page.
#129729) Fixes#129696. When a single type load needs both an unboxing and non-unboxing entrypoint at the same time, we'd build the same generic dictionary twice and fail during registration. The surgical fix is to allow type loader to do the work twice, but stop at the point where we would try to allocate it. Runtime type loader having unboxing MethodDescs was a mistake. This is not a problem if we don't need both at the same time since the all the lookups for existing dictionary already ignore the unboxing bit. (Which is why we fail during registration in the bug - unboxing bit is not part of the key.) No regression test because the test is in #128702.
Fixes#129696.
When a single type load needs both an unboxing and non-unboxing entrypoint at the same time, we'd build the same generic dictionary twice and fail during registration. The surgical fix is to allow type loader to do the work twice, but stop at the point where we would try to allocate it. Runtime type loader having unboxing MethodDescs was a mistake.
This is not a problem if we don't need both at the same time since the all the lookups for existing dictionary already ignore the unboxing bit. (Which is why we fail during registration in the bug - unboxing bit is not part of the key.)
No regression test because the test is in #128702.