Skip to content

[WIP] Fix to move to using GC pal within coreclr on Linux - #78521

Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from
mangod9:port-gc-pal
Closed

[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from
mangod9:port-gc-pal

Conversation

@mangod9

@mangod9mangod9 commented Nov 17, 2022

Copy link
Copy Markdown
Member

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.

janvorliand others added 4 commits November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9 added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) area-GC-coreclr labels Nov 17, 2022
@ghost

ghost commented Nov 17, 2022

Copy link
Copy Markdown

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

Issue Details

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.

Author:mangod9
Assignees:-
Labels:

NO-MERGE, area-GC-coreclr

Milestone:-

@ghostghost assigned mangod9Nov 17, 2022
@mangod9
mangod9 marked this pull request as draft November 17, 2022 19:56
@carlossanlop

carlossanlop commented Nov 21, 2022

Copy link
Copy Markdown
Contributor

@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.

@mangod9

mangod9 commented Nov 21, 2022

Copy link
Copy Markdown
MemberAuthor

@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.

@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9 added this to the 7.0.3 milestone Nov 29, 2022
@ghostghost closed this Dec 29, 2022
@ghost

ghost commented Dec 29, 2022

Copy link
Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

@carlossanlop

carlossanlop commented Jan 4, 2023

Copy link
Copy Markdown
Contributor

@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.

@mangod9

mangod9 commented Jan 4, 2023

Copy link
Copy Markdown
MemberAuthor

No we have decided to do another fix as part of this PR instead: #80173

@carlossanlopcarlossanlop removed this from the 7.0.3 milestone Jan 5, 2023
@ghostghost locked as resolved and limited conversation to collaborators Feb 5, 2023
This pull request was closed.
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
[WIP] Fix to move to using GC pal within coreclr on Linux by mangod9 · Pull Request #78521 · dotnet/runtime · GitHub
Skip to content
[WIP] Fix to move to using GC pal within coreclr on Linux - #78521
Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Closed
[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Conversation
@mangod9
@mangod9mangod9
commented
Nov 17, 2022

Copy link


Copy Markdown

Member
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.
janvorliand others
added 4 commits
November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9
added

NO-MERGE
The PR is not ready for merge yet (see discussion for detailed reasons)
area-GC-coreclr

labels
Nov 17, 2022
@ghost
ghost
commented
Nov 17, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/gc

See info in area-owners.md if you want to be subscribed.
Issue Details
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.
Author:mangod9
Assignees:-
Labels:
NO-MERGE, area-GC-coreclr
Milestone:-
@ghostghost
assigned mangod9Nov 17, 2022
@mangod9
mangod9
marked this pull request as draft
November 17, 2022 19:56
@carlossanlop
carlossanlop
commented
Nov 21, 2022

Copy link


Copy Markdown

Contributor
@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.
@mangod9
mangod9
commented
Nov 21, 2022

Copy link


Copy Markdown

MemberAuthor
@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.
@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9
added this to the 7.0.3 milestone
Nov 29, 2022
@ghostghost
closed this
Dec 29, 2022
@ghost
ghost
commented
Dec 29, 2022

Copy link


Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.
@carlossanlop
carlossanlop
commented
Jan 4, 2023

Copy link


Copy Markdown

Contributor
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.
@mangod9
mangod9
commented
Jan 4, 2023

Copy link


Copy Markdown

MemberAuthor
No we have decided to do another fix as part of this PR instead: #80173
@carlossanlopcarlossanlop
removed this from the 7.0.3 milestone
Jan 5, 2023
@ghostghost
locked as resolved and limited conversation to collaborators
Feb 5, 2023

This pull request was closed.

Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[WIP] Fix to move to using GC pal within coreclr on Linux by mangod9 · Pull Request #78521 · dotnet/runtime · GitHub
Skip to content
[WIP] Fix to move to using GC pal within coreclr on Linux - #78521
Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Closed
[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Conversation
@mangod9
@mangod9mangod9
commented
Nov 17, 2022

Copy link


Copy Markdown

Member
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.
janvorliand others
added 4 commits
November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9
added

NO-MERGE
The PR is not ready for merge yet (see discussion for detailed reasons)
area-GC-coreclr

labels
Nov 17, 2022
@ghost
ghost
commented
Nov 17, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/gc

See info in area-owners.md if you want to be subscribed.
Issue Details
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.
Author:mangod9
Assignees:-
Labels:
NO-MERGE, area-GC-coreclr
Milestone:-
@ghostghost
assigned mangod9Nov 17, 2022
@mangod9
mangod9
marked this pull request as draft
November 17, 2022 19:56
@carlossanlop
carlossanlop
commented
Nov 21, 2022

Copy link


Copy Markdown

Contributor
@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.
@mangod9
mangod9
commented
Nov 21, 2022

Copy link


Copy Markdown

MemberAuthor
@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.
@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9
added this to the 7.0.3 milestone
Nov 29, 2022
@ghostghost
closed this
Dec 29, 2022
@ghost
ghost
commented
Dec 29, 2022

Copy link


Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.
@carlossanlop
carlossanlop
commented
Jan 4, 2023

Copy link


Copy Markdown

Contributor
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.
@mangod9
mangod9
commented
Jan 4, 2023

Copy link


Copy Markdown

MemberAuthor
No we have decided to do another fix as part of this PR instead: #80173
@carlossanlopcarlossanlop
removed this from the 7.0.3 milestone
Jan 5, 2023
@ghostghost
locked as resolved and limited conversation to collaborators
Feb 5, 2023

This pull request was closed.

Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[WIP] Fix to move to using GC pal within coreclr on Linux by mangod9 · Pull Request #78521 · dotnet/runtime · GitHub
Skip to content
[WIP] Fix to move to using GC pal within coreclr on Linux - #78521
Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Closed
[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Conversation
@mangod9
@mangod9mangod9
commented
Nov 17, 2022

Copy link


Copy Markdown

Member
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.
janvorliand others
added 4 commits
November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9
added

NO-MERGE
The PR is not ready for merge yet (see discussion for detailed reasons)
area-GC-coreclr

labels
Nov 17, 2022
@ghost
ghost
commented
Nov 17, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/gc

See info in area-owners.md if you want to be subscribed.
Issue Details
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.
Author:mangod9
Assignees:-
Labels:
NO-MERGE, area-GC-coreclr
Milestone:-
@ghostghost
assigned mangod9Nov 17, 2022
@mangod9
mangod9
marked this pull request as draft
November 17, 2022 19:56
@carlossanlop
carlossanlop
commented
Nov 21, 2022

Copy link


Copy Markdown

Contributor
@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.
@mangod9
mangod9
commented
Nov 21, 2022

Copy link


Copy Markdown

MemberAuthor
@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.
@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9
added this to the 7.0.3 milestone
Nov 29, 2022
@ghostghost
closed this
Dec 29, 2022
@ghost
ghost
commented
Dec 29, 2022

Copy link


Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.
@carlossanlop
carlossanlop
commented
Jan 4, 2023

Copy link


Copy Markdown

Contributor
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.
@mangod9
mangod9
commented
Jan 4, 2023

Copy link


Copy Markdown

MemberAuthor
No we have decided to do another fix as part of this PR instead: #80173
@carlossanlopcarlossanlop
removed this from the 7.0.3 milestone
Jan 5, 2023
@ghostghost
locked as resolved and limited conversation to collaborators
Feb 5, 2023

This pull request was closed.

Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
[WIP] Fix to move to using GC pal within coreclr on Linux by mangod9 · Pull Request #78521 · dotnet/runtime · GitHub
Skip to content
[WIP] Fix to move to using GC pal within coreclr on Linux - #78521
Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Closed
[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Conversation
@mangod9
@mangod9mangod9
commented
Nov 17, 2022

Copy link


Copy Markdown

Member
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.
janvorliand others
added 4 commits
November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9
added

NO-MERGE
The PR is not ready for merge yet (see discussion for detailed reasons)
area-GC-coreclr

labels
Nov 17, 2022
@ghost
ghost
commented
Nov 17, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/gc

See info in area-owners.md if you want to be subscribed.
Issue Details
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.
Author:mangod9
Assignees:-
Labels:
NO-MERGE, area-GC-coreclr
Milestone:-
@ghostghost
assigned mangod9Nov 17, 2022
@mangod9
mangod9
marked this pull request as draft
November 17, 2022 19:56
@carlossanlop
carlossanlop
commented
Nov 21, 2022

Copy link


Copy Markdown

Contributor
@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.
@mangod9
mangod9
commented
Nov 21, 2022

Copy link


Copy Markdown

MemberAuthor
@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.
@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9
added this to the 7.0.3 milestone
Nov 29, 2022
@ghostghost
closed this
Dec 29, 2022
@ghost
ghost
commented
Dec 29, 2022

Copy link


Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.
@carlossanlop
carlossanlop
commented
Jan 4, 2023

Copy link


Copy Markdown

Contributor
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.
@mangod9
mangod9
commented
Jan 4, 2023

Copy link


Copy Markdown

MemberAuthor
No we have decided to do another fix as part of this PR instead: #80173
@carlossanlopcarlossanlop
removed this from the 7.0.3 milestone
Jan 5, 2023
@ghostghost
locked as resolved and limited conversation to collaborators
Feb 5, 2023

This pull request was closed.

Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[WIP] Fix to move to using GC pal within coreclr on Linux by mangod9 · Pull Request #78521 · dotnet/runtime · GitHub
Skip to content
[WIP] Fix to move to using GC pal within coreclr on Linux - #78521
Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Closed
[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Conversation
@mangod9
@mangod9mangod9
commented
Nov 17, 2022

Copy link


Copy Markdown

Member
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.
janvorliand others
added 4 commits
November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9
added

NO-MERGE
The PR is not ready for merge yet (see discussion for detailed reasons)
area-GC-coreclr

labels
Nov 17, 2022
@ghost
ghost
commented
Nov 17, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/gc

See info in area-owners.md if you want to be subscribed.
Issue Details
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.
Author:mangod9
Assignees:-
Labels:
NO-MERGE, area-GC-coreclr
Milestone:-
@ghostghost
assigned mangod9Nov 17, 2022
@mangod9
mangod9
marked this pull request as draft
November 17, 2022 19:56
@carlossanlop
carlossanlop
commented
Nov 21, 2022

Copy link


Copy Markdown

Contributor
@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.
@mangod9
mangod9
commented
Nov 21, 2022

Copy link


Copy Markdown

MemberAuthor
@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.
@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9
added this to the 7.0.3 milestone
Nov 29, 2022
@ghostghost
closed this
Dec 29, 2022
@ghost
ghost
commented
Dec 29, 2022

Copy link


Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.
@carlossanlop
carlossanlop
commented
Jan 4, 2023

Copy link


Copy Markdown

Contributor
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.
@mangod9
mangod9
commented
Jan 4, 2023

Copy link


Copy Markdown

MemberAuthor
No we have decided to do another fix as part of this PR instead: #80173
@carlossanlopcarlossanlop
removed this from the 7.0.3 milestone
Jan 5, 2023
@ghostghost
locked as resolved and limited conversation to collaborators
Feb 5, 2023

This pull request was closed.

Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[WIP] Fix to move to using GC pal within coreclr on Linux by mangod9 · Pull Request #78521 · dotnet/runtime · GitHub
Skip to content
[WIP] Fix to move to using GC pal within coreclr on Linux - #78521
Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Closed
[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Conversation
@mangod9
@mangod9mangod9
commented
Nov 17, 2022

Copy link


Copy Markdown

Member
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.
janvorliand others
added 4 commits
November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9
added

NO-MERGE
The PR is not ready for merge yet (see discussion for detailed reasons)
area-GC-coreclr

labels
Nov 17, 2022
@ghost
ghost
commented
Nov 17, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/gc

See info in area-owners.md if you want to be subscribed.
Issue Details
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.
Author:mangod9
Assignees:-
Labels:
NO-MERGE, area-GC-coreclr
Milestone:-
@ghostghost
assigned mangod9Nov 17, 2022
@mangod9
mangod9
marked this pull request as draft
November 17, 2022 19:56
@carlossanlop
carlossanlop
commented
Nov 21, 2022

Copy link


Copy Markdown

Contributor
@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.
@mangod9
mangod9
commented
Nov 21, 2022

Copy link


Copy Markdown

MemberAuthor
@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.
@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9
added this to the 7.0.3 milestone
Nov 29, 2022
@ghostghost
closed this
Dec 29, 2022
@ghost
ghost
commented
Dec 29, 2022

Copy link


Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.
@carlossanlop
carlossanlop
commented
Jan 4, 2023

Copy link


Copy Markdown

Contributor
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.
@mangod9
mangod9
commented
Jan 4, 2023

Copy link


Copy Markdown

MemberAuthor
No we have decided to do another fix as part of this PR instead: #80173
@carlossanlopcarlossanlop
removed this from the 7.0.3 milestone
Jan 5, 2023
@ghostghost
locked as resolved and limited conversation to collaborators
Feb 5, 2023

This pull request was closed.

Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
[WIP] Fix to move to using GC pal within coreclr on Linux by mangod9 · Pull Request #78521 · dotnet/runtime · GitHub
Skip to content
[WIP] Fix to move to using GC pal within coreclr on Linux - #78521
Closed
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Closed
[WIP] Fix to move to using GC pal within coreclr on Linux#78521
mangod9 wants to merge 5 commits into
dotnet:release/7.0from 
mangod9:port-gc-pal
Conversation
@mangod9
@mangod9mangod9
commented
Nov 17, 2022

Copy link


Copy Markdown

Member
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.
janvorliand others
added 4 commits
November 10, 2022 10:20
@janvorli@mangod9
Modify __int64 definition in PAL to match the OS definition (dotnet#7…
ef751dc
…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
@janvorli@mangod9
Fix the __int64 to be long long on macOS only (dotnet#77268)
8183541
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.
@mangod9
statically linking GC PAL on linux (dotnet#76985)
16495db
* 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.
@mangod9
check the right return value for mmap (dotnet#77952)
540ea21
@mangod9mangod9
added

NO-MERGE
The PR is not ready for merge yet (see discussion for detailed reasons)
area-GC-coreclr

labels
Nov 17, 2022
@ghost
ghost
commented
Nov 17, 2022

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/gc

See info in area-owners.md if you want to be subscribed.
Issue Details
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.
Author:mangod9
Assignees:-
Labels:
NO-MERGE, area-GC-coreclr
Milestone:-
@ghostghost
assigned mangod9Nov 17, 2022
@mangod9
mangod9
marked this pull request as draft
November 17, 2022 19:56
@carlossanlop
carlossanlop
commented
Nov 21, 2022

Copy link


Copy Markdown

Contributor
@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.
@mangod9
mangod9
commented
Nov 21, 2022

Copy link


Copy Markdown

MemberAuthor
@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.
@mangod9
fixing alignment check which affects MacOS
520c8c3
This was manually picked from: dotnet#75264 which was already present in main, before the PAL change.
@mangod9mangod9
added this to the 7.0.3 milestone
Nov 29, 2022
@ghostghost
closed this
Dec 29, 2022
@ghost
ghost
commented
Dec 29, 2022

Copy link


Copy Markdown

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.
@carlossanlop
carlossanlop
commented
Jan 4, 2023

Copy link


Copy Markdown

Contributor
@mangod9 FYI this got autoclosed due to inactivity. Ping me if this needs to get reopened for 7.0.3. There is still time.
@mangod9
mangod9
commented
Jan 4, 2023

Copy link


Copy Markdown

MemberAuthor
No we have decided to do another fix as part of this PR instead: #80173
@carlossanlopcarlossanlop
removed this from the 7.0.3 milestone
Jan 5, 2023
@ghostghost
locked as resolved and limited conversation to collaborators
Feb 5, 2023

This pull request was closed.

Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

Copilot code reviewCopilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

@mangod9mangod9

Labels

area-GC-coreclrNO-MERGEThe PR is not ready for merge yet (see discussion for detailed reasons)

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@mangod9@carlossanlop@janvorli