-
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
[WIP] Fix to move to using GC pal within coreclr on Linux #78521
Conversation
…7056) * Modify __int64 definition in PAL to match the OS definition This change modifies the definition of __int64 and thus of many other types defined on the basis of it to match the OS definitions. This ensures that we can use these types in interfaces between code in coreclr and various PALs that are compiled against OS headers. The key issue was that we were defining __int64 for 64 bit OSes as long while Unix defines it as long long. The size of those types is the same on Unix, but they are different and result in different mangling of C++ names. * Fix coreclr tests build * Fix comment on #endif in jit.h * Reflect PR feedback * Fix jit source formatting * Fix FreeBSD build
It turned out that my recent change to redefine __int64 on Unix is actually correct for macOS only. For other 64 bit Unixes, the __int64 should be defined as long. This change fixes it.
* statically linking GC PAL The GC PAL will be used for both coreclr and standalone GC on linux * fixing arm64 and nativeaot build breaks * macos build break and reducing renaming. * trying to remove numa support from PAL * one more rename to resolve MacOS break * delete pal numa code. * Adding missing madvise in GC PAL * added missing MADV_DONTDUMP calls. * CR feedback * undo (long long) cast in GetMemoryStatus * only invoke madvise on success.
Tagging subscribers to this area: @dotnet/gc Issue DetailsThis reduces the coreclr PAL overhead with large reservation size (~64mb) improvement in resident size. Not ready to merge yet -- will validate in various CI runs.
|
@mangod9 do we intend to merge this for the January Release? If yes, can you please make sure the PR is ready to merge before Nov. 29th? I ask because for the January release, we will only have a one day window to merge servicing PRs, so I want to make sure all the PRs are 100% ready on that day for me to just click the merge button. That window is from Nov. 29th to Nov. 30th. |
@carlossanlop, thanks for the info. This is not ready for approval yet -- still needs investigation on some test failures. But will try to get it ready before 11/29 if possible. Thx. |
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time. |
No we have decided to do another fix as part of this PR instead: #80173 |
This reduces the coreclr PAL overhead with large reservation size (~64mb) improvement in resident size. Not ready to merge yet -- will validate in various CI runs.