Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Cached interface dispatch for coreclr #111771
base: main
Are you sure you want to change the base?
Cached interface dispatch for coreclr #111771
Changes from 32 commits
2b2ca52
4892674
d69528f
5f1f2b5
976bf83
652930c
39a2574
4c0865c
645c487
921631a
73b0b26
2cdd955
edad834
df393d9
cce3bcb
4bbcdaa
c320e1d
361588a
24e78b2
5b0e5ac
fa7826a
f1c2c65
36c9cc0
9377342
a3a4ff1
18b3f13
80ae02b
081fac5
a0b9d2a
dcbe17c
6e5a394
48b5009
ad64a55
fa72602
08ac0a1
006537d
2ff4d2a
6cb2b78
70dacc0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
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.
Can we get a small comment here on why the CacheEntryHeap is not used in the caching logic? I'm ignorant of this area and it feels odd that the VirtualCallStubManager is used, but ignored in some cases. Perhaps an assert or some other breadcrumb to indicate why this isn't appropriate.
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.
We could use it, and possibly should, but as I noted in the PR description, I intentionally disabled this feature since it was more work to enable, and this change is already too big for easy development. If we decide that this sort of caching is advantageous, it would be appropriate in a separate PR to enable it for the cached interface dispatch scenario.
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.
This adds to the confusion from above considering
case CacheEntryHeap:
remains, but we define out the string.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.
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.
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.
https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/clr-abi.md#hidden-parameters should be updated too.
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.
AAGGHH.. reading this has sent me down the rabbit hole of sadness which has told me that I need to move both CoreCLR and NativeAOT to use r10, and not to r11 as that is the only way to keep CFG from exploding sadly. (Or I can keep the difference between CoreCLR and NativeAOT).
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.
I like the idea of getting these unified as you may guess.
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.
Or rather... this won't break stuff, but the codegen for CFG is required to be a bit non-ideal in native aot..OTOH, it appears with some quick testing that this doesn't actually effect the codegen in any case, since our CFG generation logic isn't what I'd call great right now, so I'd like to keep moving everything to r11. If we want to use r10 we can swap back all of the amd64 stuff at once.
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.
It would be nice if we added the
InterlockedCompareExchange128
to theVMToOSInterface
above and implemented it for Unix / Windows in the respective subfolders.When I have started with this minipal, the intent was that all stuff that needs to be platform specific will go there. Once we get rid of coreclr PAL, this was meant to be the only place for platform specific code.
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.
Unfortunately, this is a case where we want to have a shared set of PAL apis between CoreCLR and NativeAOT, and NativeAOT hasn't moved towards the VmToOSInterface idea (And this change is already WAY too big to add that to it.) I'd welcome some rationalization after this is all merged.
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.
A nit - we don't have any folders that have names with underscores, it would be nice to stay consistent.
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.
I'd like to hear opinions on the directory structure from several people here. @AaronRobinsonMSFT might also be interested to comment on this.
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.
jit
andgc
are shared too, but they do not haveshared_
in the name. I am not a fan of theshared_
prefix.Maybe just call it
runtime
?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.
runtime
seems appropriate. I agree that a prefix would be nice, but I agree with @janvorli's consistency argument. @jkotas's dislike ofshared_
is something I share too. I thinkshared
is also dangerous as it breeds a dumping ground akin toutils
.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.
runtime it is. I'll make the changes soon.
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.
I'll be leaving the CMAKE name of the directory as SHARED_RUNTIME_DIR though, as RUNTIME_DIR is already taken for src/coreclr/nativeaot/Runtime
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.
Rename
RUNTIME_DIR
->NATIVEAOT_RUNTIME_DIR
andSHARED_RUNTIME_DIR
->RUNTIME_DIR
? There are only 25 instances ofRUNTIME_DIR
spread over 4 files.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.
I get that perhaps the
Alloc()
provides this guarantee, but it looks odd for one to call out alignment and use an explicit API and the other providing a similar guarantee and calling a seemingly more general function. It also looks likeAlloc()
callsAllocAligned()
and passes1
, so now I have more questions.