[DISCUSS][CORE] Should managed off-heap memory take the container limit into account?

[920032148]

I have been looking at how Spark managed off-heap memory behaves in a memory-limited container.
One thing that seems easy to misconfigure is that these three limits are independent:

container limit:                 1500 MiB
JVM max heap:                    1024 MiB
spark.memory.offHeap.size:       2048 MiB

spark.memory.offHeap.size is only an upper bound used by Spark's memory manager, so the example
above does not fail immediately. The problem is that UnifiedMemoryManager does not know about the
1500 MiB process limit. If heap, managed off-heap memory, direct buffers, thread stacks, and other
native allocations grow at the same time, the container can kill the executor before Spark gets a
chance to spill.

In that case there may be no useful Java OOM. From outside the container it can just look like:

exit code 137
OOMKilled=true

Using JVM heap occupancy as the feedback signal does not seem right here. It cannot see off-heap
or other native memory, and it moves with GC. The cgroup usage and limit describe the boundary that
actually kills the process.

I made a small prototype that reads cgroup v1/v2 values and uses them to put a lower admission
limit on Spark-managed off-heap memory. At startup the rough budget is:

cgroup limit - JVM max heap - native reserve

The admission limit can then be reduced when total cgroup usage is high. This still relies on the
existing MemoryConsumer and spill code; it does not add another eviction mechanism.

There are some non-obvious details. In particular, setting the limit to zero is not safe because a
task may fail to allocate its first sorter page and throw SparkOutOfMemoryError instead of
spilling. Also, a fixed native reserve is probably too simplistic across different collectors,
core counts, and deployment modes.

Before spending more time on the prototype, I would like to check the expected direction:

1. Should Spark use the container limit when admitting managed off-heap allocations, or is this
   expected to be handled entirely by executor memory-overhead configuration?
2. If Spark should handle it, would a startup warning/static cap be preferable to runtime
   cgroup-pressure feedback?

If this belongs in Spark Core, I can follow up with a focused reproducer and tests for the approach
maintainers prefer.