Convert small atomic fallbacks to managed

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks

[MichalPetryka]

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

[ghost]

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

Issue Details

---

Makes the non-intrinsic implementations of Exchange/CompareExchange for small types be implemented as loops using 32b variants instead of calling into native code.

I'm not sure what's the performance difference here as the only platforms that should use those will be RISC-V and Mono (ARM32 is handled with #97792 and LoongArch64 seems trivial to do but I have no way to test it).

I've based the idea for the implementation on the fact that Linux Kernel and Libatomic use such 32b operations for their fallbacks (I took no code from those however as they're both GPL).
The approach also relies on an implementation detail of the GCs with that it'll keep refs backtracked to 4B aligned and in the same object to avoid pinning.

I'm not 100% sure whether doing this in managed makes sense here since it's a lot of code, but it also removed all the C++ paths from 3 runtimes.
cc @jkotas

Author:	MichalPetryka
Assignees:	-
Labels:	area-System.Threading, needs-area-label
Milestone:	-

[jkotas]

Is AggressiveInlining here just a copy&paste? It does not sound like a good idea to aggressively inline all this.

[MichalPetryka]

I assume this should be similar in size to what native compilers emit for RISC-V and they do inline that.

[MichalPetryka]

One benefit to inlining this is that with #99130 it lets the JIT fold most of the bit operations here when passed a ref to a static field.

[jkotas]

I think it is fine to do this for CoreCLR/NativeAOT. As you have said, it is just a fallback that should be only used during platform bring up. We effectively require JIT to expand these inline for best perf.

I am not sure about Mono. @vargaz@AlekseyTs Thoughts?

[MichalPetryka]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

[jkotas]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

cc @gbalykov@HJLeee@wscho77@clamp03@JongHeonChoi@t-mustafin@viewizard

[MichalPetryka]

exit code 139 means SIGSEGV Illegal memory access. Deref invalid pointer, overrunning buffer, stack overflow etc. Core dumped.

Seems like Mono crashes with this implementation, could somebody say if the implementation assumptions are invalid there or if there's some bug instead?

[jkotas]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

[MichalPetryka]

You may want to temporarily enable the fallback implementation for CoreCLR and see whether it passes all tests.

It's currently tested with ARM32 and it asserts which I've fixed in #99019.
I've ran it locally on X64 beforehand and it passed for me (even with GCStress, which would actually be nice to run here).

[clamp03]

It'd be nice if somebody from the Samsung RISC-V team could benchmark this on a RISC-V device to see the performance difference.

I am out of office. @bartlomiejko Could your team can check the performance difference?

[MichalPetryka]

All failures here seem unrelated, this seems to be only waiting for a review of the assumptions on Mono I think.
EDIT: I've also added some more tests for asserts I've seen locally but that should be fixed with #99019.

[MichalPetryka]

Seems like there's still some assert here:

Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe
ERROR:
Assert failure(PID 26748 [0x0000687c], Thread: 36716 [0x8f6c]): Assertion failed 'CoercedConstantValue<size_t>(vn) != 0' in 'InterlockedDisasm:Cas(int):ubyte' during 'Do value numbering' (IL size 18; hash 0x0e503796; FullOpts)
File: H:\Projects\dotnet\runtime\src\coreclr\jit\valuenum.cpp:1630
Image: H:\Projects\dotnet\runtime\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[MichalPetryka]

there's still some assert

Fixed now with #100060.

I am not sure about Mono.

I guess we still need somebody from the Mono team to check this?

[hamarb123]

Remove Unsafe.AsPointer uses

[lambdageek]

Mono LGTM

@MichalPetryka I would leave the small ops in atomic.h - they are generally useful. Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

[MichalPetryka]

I would leave the small ops in atomic.h - they are generally useful.

I could do that but I think they're simple enough that they could be readded when needed.

Also it might be worthwhile to open a follow-up issue for mono to add intrinsics for these operations in the JIT and interpreter.

#93488

[MichalPetryka]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

[mangod9]

@jkotas does the musl arm assert here seem related to the changes here for you?

runtime/src/coreclr/vm/methodtable.cpp

Line 7377 in ac07ea6

_ASSERTE((GetComponentSize() <= 2) || IsArray());

This is a known issue logged here: #86273

[MichalPetryka]

This seems ready to merge I think but it'll slightly conflict with #100021 so I'm not sure which one should go in first cc @jkotas

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks