Closed
Description
A tracking issue for FOH-related tasks (Frozen Object Heap). It's a special heap for immortal objects such as string literals, Type objects, etc (see the list below). Conceptually similar to POH but it doesn't have a public API thus it never contains short-living objects + there are some relaxations in GC for FOH. It provides two advantages:
- Makes GC's life easier by moving immortal objects out of normal heap
- For some objects VM no longer needs to allocate pinned handles
- JIT can "bake" direct references to FOH objects in codegen, see example.
- Unlocks some JIT optimizations like folding field accesses for immutable objects, fold objects comparisons, etc.
.NET 8.0
- Allocate string literals on FOH Allocate string literals on frozen segments #49576
- Allocate Type objects on FOH Allocate RuntimeType objects on Frozen Object Heap #75573 (and JIT: import static readonly fields holding frozen objects as const handles #76112)
- Optimize
static readonly
fields holding frozen objects to const handles JIT: import static readonly fields holding frozen objects as const handles #76112 - Don't use write-barriers for FOH objects JIT: Don't use write barriers for frozen objects #76135
- Allocate simple
static readonly
fields on FOH e.g.static readonly object SyncObj = new();
and arrays Allocate Array.Empty<> on a frozen segment (NonGC heap) #85559 - Allocate boxes statics on FOH Allocate boxed static structs on Frozen Object Heap #77737
- [In PR] Diagnostic support Diagnostic support for NonGC heap diagnostics#4156 (and thread in Allocate string literals on frozen segments #49576)
- Better heuristics for size of frozen segments: Double the size of new frozen segments #76870
- Testing on real-world workloads (1P/3P)
- How many objects end up in FOH, what's the ratio between SOH and FOH typically.
- Standalone GC
- Hard heap limit
- Performance impact/savings
- Bug-fixes:
Suggestions are very welcome!
category:planning
theme:memory-usage
skill-level:expert
cost:medium
impact:medium