Skip to content

[CoreCLR] Remove DSO-cache hashes: decouple JNI preload and rework p/invoke fallback #12039

Description

@simonrozsival

Context

After #12010 (p/invoke override rewritten to plain string comparisons) and #12033 (dlopen-based assembly store loading, which removes DSOApkEntry and the ZIP-scan fast path), the only remaining functional consumer of DSOCacheEntry.hash in the CoreCLR host is the p/invoke fallback lookup (MonodroidDl::find_dso_cache_entry, called once from monodroid_dlopen(name)).

JNI shared-library preloading (host.cc) uses the dso_cache array too, but it needs no hashes: it is driven by dso_jni_preloads_idx (a list of indexes) → DSOCacheEntry::name_index → name → System.loadLibrary. entry.hash appears there only as a log_debug argument, and entry.real_name_hash is only used by find_dso_apk_entry, which #12033 deletes.

In other words, preload and "resolve an arbitrary p/invoke library by name" are two unrelated concerns fused into one hash-indexed table; the hashes exist solely for the fallback lookup.

Blocked on

Both actively rewrite the same files (precompiled.cc, pinvoke-override*.hh, monodroid-dl.hh, the CLR app-config generator), so this cleanup should land on a stable base to avoid churn/conflicts.

Work

  1. Decouple JNI preload into a standalone, hash-free list of names (generator side in ApplicationConfigNativeAssemblyGeneratorCLR.cs + the preload loop in host.cc). No dependency on DSOCacheEntry hash fields.
    • Note on handle sharing: today preload writes the loaded handle back into dso_cache (+ alias entries) so a later p/invoke reuses it. If decoupled, a preloaded lib later hit by p/invoke simply re-resolves via System.loadLibrary (idempotent → same handle, negligible cost). Correctness is preserved.
  2. Rework/remove the p/invoke fallback lookup (monodroid_dlopen(name) → find_dso_cache_entry), aligned with the [CoreCLR] Remove robin-map from p/invoke override #12010 direction of letting CoreCLR's own resolver / System.loadLibrary handle arbitrary libraries.
  3. Once (1) and (2) are done, dso_cache collapses to just preload names → drop DSOCacheEntry.hash / real_name_hash and remove CRC32 from the CoreCLR DSO path entirely.

Out of scope / note

#12013 ("[CoreCLR] Replace xxhash with crc32") deliberately only does the mechanical xxHash→CRC32 swap on the surviving fallback lookup. It does not attempt the decoupling or fallback rework above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-triageIssues that need to be assigned.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions