Proposal: Spans for JNI Member lookups

[jonpryor]

Currently, Java.Interop.JniPeerMembers member lookups are backed via dictionary lookup with string as the key-type, e.g.

https://github.com/xamarin/java.interop/blob/7dc270dbb83948b278bee38fc83bf9ae5cd42a7e/src/Java.Interop/Java.Interop/JniPeerMembers.JniStaticMethods.cs#L18
https://github.com/xamarin/java.interop/blob/7dc270dbb83948b278bee38fc83bf9ae5cd42a7e/src/Java.Interop/Java.Interop/JniPeerMembers.JniStaticMethods.cs#L25-L36

This works, and provides a reasonably "user-friendly" interface, but has hidden performance implications:

• JniPeerMembers.GetNameAndSignature() allocates strings, which creates "garbage" objects, as they're not long-lived: https://github.com/xamarin/java.interop/blob/7dc270dbb83948b278bee38fc83bf9ae5cd42a7e/src/Java.Interop/Java.Interop/JniPeerMembers.cs#L183-L188
• The dictionary lookup requires traversing the entire encodedMember string, which is a (usually fast!) O(n) operation.
• There is "implicit" marshaling overhead, as e.g. JniType.GetStaticMethod() involves a P/Invoke, which marshals a UTF-16 string instance to a UTF-8 native string: https://github.com/xamarin/java.interop/blob/7dc270dbb83948b278bee38fc83bf9ae5cd42a7e/src/Java.Interop/Java.Interop/JniType.cs#L252-L257

(Note: this still appears to contribute ~2ms to Xamarin.Android app startup, so it's not a huge source of performance implications, but it is A Thing™ to consider…)

These methods are usually invoked via generator-emitted code, such as:

namespace Android.App {
	public partial class Activity {
		public static unsafe long InstanceCount {
			[Register ("getInstanceCount", "()J", "")]
			get {
				const string __id = "getInstanceCount.()J";
				try {
					var __rm = _members.StaticMethods.InvokeInt64Method (__id, null);
					return __rm;
				} finally {
				}
			}
		}
	}
}

We could improve this by:

1. Pre-compute a hashcode value.
2. Use Span<T> types, which
3. Use byte instead of char, and
4. Contain embedded nulls

Thus, instead of:

const string __id = "getInstanceCount.()J";
var __rm = _members.StaticMethods.InvokeInt64Method (__id, null);

We would instead have generator emit:

static readonly int hash_getInstanceCount = JniPeerMembers.ComputeHash ("getInstanceCount.()J");
…
ReadOnlySpan<byte> __id = new stackalloc {
    (byte) 'g',
    (byte) 'e',
    …
    (byte) 't',
    (byte) 0,  // terminates `getInstanceCount`
    (byte) '.'
    (byte) '(',
    (byte) ')',
    (byte) 'J',
    (byte) 0, // terminates `()J`
};
var __rm = _members.StaticMethods.InvokeInt64Method (hash_getInstanceCount, __id, null);

JniEnvironment.StaticMethods.GetStaticMethodID() & co. could then be overloaded to take ReadOnlySpan<T> parameters (as overloads to the current string parameters).

TODO: verify that ReadOnlySpan<byte> as a P/Invoke parameter (1) works, and (2) passes the data as-is, no copy or marshaling involved.

Doing all this would remove the need to marshal anything: everything would already be UTF-8, because that's what generator's stackalloc would contain, so there's no System.String-to-const char* marshaling involved (as is currently required). This would also help with the embedded Dictionary<string, JniMethodInfo> lookup, which could now become a Dictionary<int, JniMethodInfo> lookup (as the hash is pre-computed).

On the downside, this would be a kind-of ABI break: binding assemblies using these new members couldn't be used on older Xamarin.Android SDKs/etc. (This is where multi-targeting solves everything.)

[jonathanpeppers]

Apparently this works in C# 11:

byte[] array = "hello";             // new byte[] { 0x68, 0x65, 0x6c, 0x6c, 0x6f }
Span<byte> span = "dog";            // new byte[] { 0x64, 0x6f, 0x67 }
ReadOnlySpan<byte> span = "cat";    // new byte[] { 0x63, 0x61, 0x74 }

So maybe we can avoid the stackalloc syntax?

https://devblogs.microsoft.com/dotnet/csharp-11-preview-updates/#utf-8-string-literals

[simonrozsival]

Experiment summary by Copilot:

PoC: UTF-8 ReadOnlySpan<byte> overloads for JNI lookups

We prototyped the approach described in this issue using C# UTF-8 string literals ("java/lang/Object"u8), which are available since C# 11 and avoid the stackalloc syntax entirely (as @jonathanpeppers noted). Here's a summary of what we did, how we benchmarked it, and what we found.

What we changed in the product

We added ReadOnlySpan<byte> overloads to the lower-level JNI lookup APIs, guarded by #if FEATURE_JNIENVIRONMENT_JI_FUNCTION_POINTERS:

• JniEnvironment.Types.FindClass(ReadOnlySpan<byte>) — bypasses Marshal.StringToCoTaskMemUTF8 entirely; uses fixed pinning to pass the span directly to JNI's FindClass
• JniType(ReadOnlySpan<byte>) constructor + GetCachedJniType(ReadOnlySpan<byte>)
• 10 public span overloads on JniType: GetInstanceMethod, GetStaticMethod, GetInstanceField, GetStaticField, GetConstructor, and their GetCached* variants — all accept ReadOnlySpan<byte> for name and signature

All overloads are purely additive — existing string-based APIs remain unchanged (no API/ABI break). We also updated ~5 internal call sites to use u8 literals with #if/#else fallbacks.

The JniPeerMembers layer (dictionary caches, GetReplacementMethodInfo) was not changed in this PoC — it requires refactoring string-keyed dictionaries and a public virtual API, which is a larger effort matching points 1-2 from the original proposal.

How we benchmarked

We created a BenchmarkDotNet project (tests/Java.Interop-Benchmarks/) running against a desktop JVM. Key setup decisions:

• InProcessNoEmitToolchain: BDN's default out-of-process toolchain can't rebuild the native cmake-based java-interop library
• LaunchCount=1: JDK only allows one JNI_CreateJavaVM per process; a shared JVM instance is reused across benchmark classes
• ShortRun job: IterationCount=5, WarmupCount=3 — sufficient for stable results on JNI calls
• MemoryDiagnoser: Tracks managed heap allocations per operation

Critical finding: ManagedObjectReferenceManager invalidates benchmarks

Our initial runs showed 42KB allocated per FindClass call — wildly unrealistic. The root cause: ManagedObjectReferenceManager (used by TestJVM) was capturing full managed stack traces (GetCurrentManagedThreadStackTrace(skipFrames:2, fNeedFileInfo:true)) on every JNI reference create/delete, allocating ~30KB of strings per operation.

This happens because the constructor reads JAVA_INTEROP_GREF_LOG independently from TestJVM.GetLogOutput() — even with the env var set to "suppress", ManagedObjectReferenceManager sees a non-empty string and creates a StreamWriter to a file literally named "suppress".

Fix: We created a NoOpObjectReferenceManager (sealed subclass of JniRuntime.JniObjectReferenceManager that only overrides GlobalReferenceCount/WeakGlobalReferenceCount to return 0) and passed it via TestJVMOptions.ObjectReferenceManager. This might be worth noting for anyone else benchmarking JNI operations.

Results (Release build, NoOp ObjectReferenceManager)

Operation	string (ns)	u8 span (ns)	Speedup	Managed Alloc
FindClass	358.6	334.9	7%	0 B
new JniType	620.2	593.6	4%	48 B
GetCachedJniType (miss)	525.3	498.5	5%	48 B
GetInstanceMethod	281.0	236.1	16%	48 B
GetStaticMethod	313.1	256.1	18%	48 B
GetConstructor	275.3	227.9	17%	48 B
GetStaticField	301.5	251.5	17%	32 B
GetCachedInstanceMethod (hit)	~1	~1	~0%	0 B
GetCachedStaticField (hit)	~1	~1	~0%	0 B

Observations:

• Method/field/constructor lookups: 16-18% faster — the sweet spot. Each lookup marshals 2 strings (name + signature); the u8 path eliminates both Marshal.StringToCoTaskMemUTF8 + Marshal.ZeroFreeCoTaskMemUTF8 calls.
• FindClass: 7% faster — only 1 string parameter, so smaller relative win.
• Cache hits: identical — both paths skip JNI entirely, as expected.
• The string path's marshal cost is invisible to MemoryDiagnoser — CoTaskMemAlloc/CoTaskMemFree operate on the native heap, not the managed GC heap. The real savings are in CPU time (no transcoding, no native alloc/free) and in native heap pressure.
• Allocations shown (48B/32B) are the JniMethodInfo/JniFieldInfo/JniType class instances themselves — same for both paths, unavoidable without converting these to structs (API break).

Side note: dead-weight fields on JNI primitive types

While investigating allocations, we audited fields on the JNI info types and found some that appear unused:

• JniMethodInfo.IsStatic (public bool, 1B + 7B padding = 8B effective): Set in constructor, never read by anything — not internally in java-interop, not in android-main, not in any test. Zero references via LSP findReferences. The caller already knows whether they called GetStaticMethod vs GetInstanceMethod.

• JniFieldInfo.IsStatic (same pattern): Also never read by anything. Same reasoning — the caller chose the static vs instance API.

• JniType.registered (bool, 8B effective with padding): Used only by RegisterWithRuntime()/UnTrack() for tracking JNI global references during JniRuntime shutdown. Zero usage in android-main — Android processes just die, they never cleanly shut down the runtime. Only relevant for desktop JVM scenarios.

These are small per-instance, but in a MAUI app with thousands of bound types, methods, and fields, the 8B overhead per instance adds up. IsStatic in particular seems like it could be deprecated since it has zero consumers. Removing it would shrink JniFieldInfo from 32B → 24B and JniMethodInfo from 48B → 40B.