-
Notifications
You must be signed in to change notification settings - Fork 2.6k
[Arm64/Unix] Use portable MP optimized new/alloc #12333
Conversation
@arm64-contrib @jkotas @janvorli The data point was flawed. The methodology of total elapsed runtime depends on the longest running test. I had disabled the longest running test(s) to fix intermittent failures. Effectively this clipped the tail, and reduce the total elapsed time 33%. It had nothing to do with this change. |
Code is largely copied from |
src/vm/arm64/stubs.cpp
Outdated
|
||
_ASSERTE(g_SystemInfo.dwNumberOfProcessors != 0); | ||
|
||
// TODO-ARM64-NYI !defined(FEATURE_IMPLICIT_TLS) Use helpers optimized w/ inline TLS access... |
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 TODO is not necessary. FEATURE_IMPLICIT_TLS
is as good as what you can get with the handcrafter helpers.
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.
The comment is for the Windows !FEATURE_IMPLICIT_TLS
case.
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 looks like FEATURE_IMPLICIT_TLS
is not defined for Windows. Am I wrong?
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.
In the root clrdefinitions.cmake:
if (CLR_CMAKE_PLATFORM_UNIX OR CLR_CMAKE_TARGET_ARCH_ARM64)
add_definitions(-DFEATURE_IMPLICIT_TLS)
set(FEATURE_IMPLICIT_TLS 1)
endif(CLR_CMAKE_PLATFORM_UNIX OR CLR_CMAKE_TARGET_ARCH_ARM64)
So for ARM64, it is defined for both Windows and Unix.
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.
Done. Closed #12332
@dotnet-bot test Ubuntu arm64 Cross Debug Build |
@jashook Could you please trigger whatever arm64 testing is appropriate? |
Currently testing is offline and I am looking into the issue. If I cannot find the solution in a reasonable amount of time it is probably worth not blocking. |
FYI, I did run this through Unix/Arm64 testing locally. |
@dotnet-bot test Ubuntu arm64 Cross Debug Build |
ping |
@dotnet-bot test Windows_NT Arm64 Checked |
Thank you for waiting @sdmaclea |
@sdmaclea looks like there is a contract violation |
@jashook What does a contract violation mean? I have seen these CONTRACT things floating around, but I haven't figured out the syntax or the tool used to check them. |
The CONTRACT things are described in https://github.com/dotnet/coreclr/blob/master/Documentation/coding-guidelines/clr-code-guide.md#2.10 They get checked as asserts at runtime - on Windows only. The contract violation is basically a special form of assertion failure. I have fixed a contract violation in #12542. Was this change included in the run? |
It is hard to say, I can restart the job to to see if it repros now. @dotnet-bot test Windows_NT Arm64 Checked |
Build timeout |
@sdmaclea Windows arm64 jobs should be clean currently. |
@dotnet-bot test Ubuntu arm64 Cross Debug Build |
@jashook FWIW Looks like arm64_debug_small_page_size_prtest pass, but arm64_debug_small_page_size_flow_prtest do not.
|
773d275
to
76e8ac2
Compare
@jkotas I removed the contract line I added. Since I do not have a Windows Arm64 platform, this the CV is not something I can easily debug. I'll open an issue to add the contract. |
@jkotas @dotnet/arm64-contrib please review and/or merge |
@dotnet/arm64-contrib Are Windows arm64 tests passing on this change? I see that
IIRC, contracts that failed on this earlier were not related to InitJITHelpers1. I do not think that there was anything wrong with the InitJITHelpers1 contract that you have added. It is ok to look into it independently since you have filled issue on it. |
@dotnet-bot test Windows_NT arm64 Checked |
76e8ac2
to
527d921
Compare
@jkotas Since I do not have Windows test platform to debug Contract violation, I disabled the change for Windows and changed #13053 to match. |
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 is some chance that the contract violation on Windows flagged a problem that exists on non-Windows as well (the runtime contract checks are Windows-only). I assume that you have done a test pass to verify that there are not regressions on Linux. (The regression will likely show up as a intermittent crash during GC.)
Yes. I have been using the patch for all my runs for the last two months. Either way, I will try to get someone from the QDT windows team to debug the Contract violation.
Will GC stress testing help flush it out? arm64 GC is not perfect yet. there are still interrmittent failures. So It may not be obvious that it is a CV related issue. |
This should be good enough.
Maybe. It is best to debug the known problem on Windows first, I think. |
@dotnet-bot test Ubuntu arm64 Cross Debug Build |
Please merge |
@@ -1086,6 +1087,31 @@ void JIT_TailCall() | |||
#if !defined(DACCESS_COMPILE) && !defined(CROSSGEN_COMPILE) | |||
void InitJITHelpers1() | |||
{ | |||
#ifdef FEATURE_PAL // TODO |
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 should be removed to support Windows
No description provided.