Make BitArray.CreateArray(ReadOnlySpan<bool>) memory safe

[EgorBo]

Makes BitArray.CreateArray(ReadOnlySpan<bool>) memory safe: drops the Unsafe.WriteUnaligned/Unsafe.Add writes (the file no longer uses Unsafe at all) in favor of Vector*.Create(span) + BinaryPrimitives.Write*LittleEndian(span, ...).

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the BitArray span-of-bool constructor’s backing implementation to avoid unsafe, unaligned writes by switching to span-based vector loads (Vector*.Create(span)) and safe little-endian stores (BinaryPrimitives.Write*LittleEndian), while preserving the existing scalar fallback behavior.

Changes:

• Replaces Unsafe.WriteUnaligned + manual ref arithmetic with BinaryPrimitives.WriteUInt{32,64}LittleEndian to write vector-produced bitmasks safely.
• Reworks the SIMD loop to advance via source = source.Slice(constant) / destination = destination.Slice(constant) and computes the scalar remainder start index from the remaining source span.

[EgorBo]

@EgorBot -windows_x64 -linux_x64 -arm --filter "Perf_BitArray.BitArrayBoolArrayCtor"

[EgorBo]

@MihuBot

[EgorBo]

@EgorBot -windows_x64 -linux_x64 -arm --filter "Perf_BitArray.BitArrayBoolArrayCtor"

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Private.CoreLib/src/System/Collections/BitArray.cs:275

• The remainder-drain path uses Vector256 operations but only guards with Vector512.IsHardwareAccelerated. Per the repo SIMD guidelines, each vector width used should be guarded by its own IsHardwareAccelerated check to avoid relying on implied ISA relationships.

                    if (Vector512.IsHardwareAccelerated &&
                        source.Length >= Vector256<byte>.Count && destination.Length >= sizeof(uint))
                    {
                        uint isFalse = Vector256.Equals(Vector256.Create(source), Vector256<byte>.Zero).ExtractMostSignificantBits();
                        BinaryPrimitives.WriteUInt32LittleEndian(destination, ~isFalse);

src/libraries/System.Private.CoreLib/src/System/Collections/BitArray.cs:218

• This block now runs for any little-endian input with length >= 8, even when all Vector*.IsHardwareAccelerated flags are false (e.g., HW intrinsics disabled). That adds extra branching and span setup work to the purely-scalar path; consider gating the block on hardware acceleration.

This issue also appears on line 271 of the same file.

            if (BitConverter.IsLittleEndian && values.Length >= sizeof(ulong))

[joshuajyue]

Hi @EgorBo,
My understanding of unsafe memory is limited but to my knowledge, prior to the regression, BitArray array constructors also used unsafe memory.
Therefore I’m not completely sure if it’s a direct cause of the regressions.

However, maybe this is not the reason for this PR — I just wanted to let you know.