Use stackalloc in TypeMapHelper to reduce allocations

[jonathanpeppers]

Each call to Encoding.GetBytes(string) allocates a new byte[] that is immediately discarded after hashing. Since TypeMapHelper is called for every Java type name during the build, these short-lived allocations add up.

This PR replaces those allocations with stackalloc + the unsafe Encoding.GetBytes(char*, int, byte*, int) overload (since the Span-based overload requires netstandard2.1+). For the rare case where encoded bytes exceed 256, it falls back to a plain new byte[] allocation.

Key details:

• Extracted a shared HashString() helper that both HashJavaName (Unicode) and HashJavaNameForCLR (UTF8) delegate to
• HashBytes now takes ReadOnlySpan<byte> so it works with both stackalloc and heap-allocated buffers
• Java type names are ASCII identifiers (e.g. android/widget/TextView), typically 20-100 chars, so the stackalloc path handles virtually all real-world usage

[Copilot]

Pull request overview

This PR reduces build-time allocations in the Java type-map hashing path by replacing per-call Encoding.GetBytes(string) allocations with ArrayPool<byte>.Shared.Rent/Return in TypeMapHelper, which is invoked for every Java type name during type-map generation.

Changes:

• Replaced Encoding.*.GetBytes(name) allocations with an ArrayPool<byte>-backed buffer in a shared HashString() helper.
• Updated hashing to operate on ReadOnlySpan<byte> so only the actual encoded byte range is hashed (excluding any extra capacity from pooled arrays).

[jonathanpeppers]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

🤖 AI Review Summary

Verdict: ✅ LGTM

Clean, well-motivated allocation reduction. The unsafe approach is justified: TypeMapHelper.cs is compiled under netstandard2.0 (Xamarin.Android.Build.Tasks) where Encoding.GetBytes(ReadOnlySpan<char>, Span<byte>) isn't available, and the file is shared directly with tmt (a modern .NET TFM tool), so the unsafe overload is the right way to get zero-allocation encoding without conditional compilation noise.

Found 1 issue:

• 💡 Code organization: Magic number 256 for the stackalloc threshold (TypeMapHelper.cs:42)

👍 Good call changing HashBytes to accept ReadOnlySpan<byte> — it works seamlessly with both the stackalloc and heap-allocated fallback. The 256-byte threshold is well-chosen: it comfortably handles real-world Java names in both Unicode (2 bytes/char → 128 char limit) and UTF-8 (1 byte/char → 256 char limit) encodings.

Note: CI is still in progress (macOS build running, main check queued). Confirm all checks pass before merging.

---

Review generated by android-reviewer from review guidelines.

Generated by Android PR Reviewer for issue #11133 · ● 523.5K