[tests] make GetObjectArray peer mismatch self-diagnosing

[jonathanpeppers]

Context

Android.RuntimeTests.JnienvArrayMarshaling.GetObjectArray was un-ignored in #12222 and has been flaky ever since — ~17 failures / 216 executions, exclusively on CoreCLR-backed configurations (Mono: 0/27, NativeAOT: 0/26).

The failure message is useless:

Expected existing Context peer, got Android.AppTests.App.
Expected: same as crc64f5183e500568449d.App@8e34fe2
But was:  crc64f5183e500568449d.App@8e34fe2

Both operands print identically, because Object.ToString() forwards to the Java toString() and both managed peers wrap the same Java instance. All we learn is "the peers differ" — not why.

Why not just fix it?

I tried. Three separate hypotheses were implemented, pushed, and disproven by CI:

1. AddPeer missing MonoVM's !value.Replaceable guard — dead end: GetPeer() returns CreatePeer()'s result to the caller before AddPeer() runs, and a deterministic bug can't produce an ~18% flake.
2. GC-bridge race — CI went green, but that's a ~52% coin flip on this failure rate; not evidence.
3. Application.Context unsynchronized lazy init — shipped, and build 1531735 still failed with GetObjectArray as the only failure, contradicting the hypothesis' own prediction.

I also could not reproduce locally in 500,000 iterations — but that "negative control" was worthless, since CI runs x86_64 emulators on macOS while I was on an arm64 physical device. It never reproduced the bug even once, so it can't disprove anything.

Logcat analysis of the failing run ruled out the obvious suspects: test ordering is deterministic (NUnit ParallelScope.None, strictly alphabetical), and there was no GC, no bridge activity, and no typemap miss in the 32 ms failure window. Notably, Android.AppTests.ApplicationTest sorts first and caches Application.Context ~35 s and ~430 tests before GetObjectArray runs — so _context is pinned long beforehand, and the registry must be changing underneath it.

What this PR does

Rather than ship a fourth guess, this makes the next CI failure actually explain itself.

JniValueManager.GetPeer() peeks the registry before creating a peer, so a mismatch means PeekPeer() missed an entry that Application.Context still holds strongly. The assert is replaced with a failure-only diagnostic that distinguishes the candidate causes:

• managed hash codes of both peers, so they can be told apart at all
• JniIdentityHashCode, PeerReference, JniManagedPeerState
• whether Application.Context still returns the captured instance
• IsSameObject() on the two peer references
• what PeekPeer() returns now — the expected peer, the unexpected one, or nothing
• every surfaced peer sharing that identity hash code

Together these separate "entry replaced by a second AddPeer()" from "entry evicted" from "weak reference cleared" — exactly the fork in the road I keep guessing at.

Risk / validation

Test-only change; no product code is touched. The diagnostic is built only on the failure path, so passing runs are unaffected.

Verified on device by temporarily forcing the failure branch: the diagnostic runs to completion without throwing (important — a secondary exception here would be worse than the original message) and reports the expected all-True values in the healthy case:

Expected `Application.Context` and `GetObjectArray ()[0]` to be the same managed peer.
  expected (Application.Context): Android.AppTests.App@managed-0x11181ff
    JniIdentityHashCode=0x116b2e2 PeerReference=0x3aea/G JniManagedPeerState=Activatable, Replaceable
  actual   (GetObjectArray ()[0]): Android.AppTests.App@managed-0x11181ff
    JniIdentityHashCode=0x116b2e2 PeerReference=0x3aea/G JniManagedPeerState=Activatable, Replaceable
  Application.Context still == expected: True
  IsSameObject (expected, actual): True
  PeekPeer (expected.PeerReference) => Android.AppTests.App@managed-0x11181ff
    is expected: True; is actual: True
  Surfaced peers with JniIdentityHashCode=0x116b2e2:
    Android.AppTests.App@managed-0x11181ff (is expected: True; is actual: True)

In a real failure those lines diverge, and the divergence names the root cause.

Contributes to #10973.

[Copilot]

Pull request overview

This PR fixes intermittent CoreCLR failures caused by duplicate managed peers being registered for the same Java instance by aligning CoreCLR’s JavaMarshalRegisteredPeers.AddPeer() replacement rules with MonoVM’s semantics.

Changes:

• Update JavaMarshalRegisteredPeers.AddPeer() to prevent replaceable peers from evicting other replaceable peers, and to replace stale entries when a peer reference is no longer valid.
• Optimize WarnNotReplacing() to avoid expensive logging work unless global reference logging is enabled.
• Add deterministic regression tests covering both replacement outcomes.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
tests/Mono.Android-Tests/Mono.Android-Tests/Mono.Android.NET-Tests.csproj	Includes the new peer-registration regression tests in the test project.
tests/Mono.Android-Tests/Mono.Android-Tests/Java.Interop/ValueManagerPeerRegistrationTests.cs	Adds deterministic tests validating replaceable/non-replaceable peer replacement semantics.
src/Mono.Android/Microsoft.Android.Runtime/JavaMarshalRegisteredPeers.cs	Aligns CoreCLR peer replacement logic with MonoVM, handles stale entries, and reduces logging overhead.