[Feature Request]: CoreCLR GC cache topology awareness for Hybrid CPUs (P/E-Cores) and upcoming bLLC architectures (Intel Nova Lake)

### Problem Statement / Motivation

With the rise of hybrid CPU architectures (P-cores / E-cores), managing Garbage Collector (GC) thread affinity and memory layout has become increasingly complex.

Currently, attempts to pin GC execution (or background GC threads) strictly to E-cores to save power or keep P-cores free for game/rendering loops often lead to **system instability, thread starvation, or severe latency spikes**.

While modern E-cores (e.g., Crestmont, Skymont) possess strong raw IPC capabilities, their primary bottleneck during heavy GC sweep/compact phases is **memory/cache bandwidth**. E-cores typically share smaller L2 caches per cluster and have limited L3 cache allocation slices. When GC threads perform massive memory traversals on E-cores, cache thrashing occurs, choking the runtime.

Furthermore, upcoming hardware architectures—such as **Intel's Nova Lake (400S series)**—are set to introduce **bLLC (Big Last Level Cache)** / dedicated cache topologies. CoreCLR needs ahead-of-time architectural preparation to adapt its GC allocation, marking, and thread scheduling strategies to these heterogeneous cache structures rather than treating all logical cores or cache lines uniformly.

---

### Proposed Behavior / Feature

We propose enhancing the CoreCLR GC engine with **Dynamic Cache & Hybrid Core Topology Awareness**:

1. **Cache-Aware GC Thread Scheduling:**
- Instead of naive core pinning or treating all logical processors as homogeneous, GC dynamic thread scheduling should consider L2/L3 cache boundaries per core type.
- Heavy GC phases (e.g., Mark/Compact) should dynamically balance work across P-cores when cache pressure on E-core clusters exceeds a threshold, preventing system instability and latency spikes.

2. **Preparation for bLLC (Nova Lake) & Large Cache Topologies:**
- Optimize GC heap segment layout and mark-stack traversals to leverage large side-caches/bLLC without invalidating L1/L2 caches of execution-critical P-cores.
- Provide better heuristic integration with Windows/Linux schedulers (e.g., Thread Director) to inform the OS about GC thread memory intensity vs. compute intensity.

---

### Alternative Solutions Considered

- **Manual OS-level Affinity Pinning:** Forcing GC threads to specific cores via environment variables or OS APIs (`SetThreadAffinityMask`). *Drawback:* Leads to cache thrashing and lock-contention instability on modern E-core clusters due to lack of internal GC state awareness.
- **Disabling E-cores entirely:** *Drawback:* Sacrifices multi-threaded throughput and efficiency on high-core-count consumer desktop CPUs.

---

### Additional Context

- **Target Area:** `area-GC`
- **Impact:** High-throughput desktop applications, C# game engines, and real-time server workloads running on Intel Alder Lake, Arrow Lake, and future Nova Lake platforms.

The issue identifies the area-GC target but names no files, tests, or entry points. Start by locating the existing GC scheduling, topology-detection, and Windows/Linux scheduler integration points; done would require an agreed, testable design and implementation for hybrid-core and cache-aware behavior.

Written by the indexing model from the issue text.