Q: Your massive Jenkins Master node repeatedly crashes heavily with `OutOfMemoryError` identically every Friday afternoon, despite possessing 32GB of RAM. You securely isolated all actual compilation execution off to distributed Jenkins worker nodes. Why is the Master still fatally crashing under load?

Even if you offload physical execution to workers natively, the Jenkins Master JVM is still heavily strictly responsible for dynamically parsing, compiling, and persistently tracking the immense Groovy AST (Abstract Syntax Tree) state for every single highly complex Declarative/Scripted Pipeline executing across the entire cluster.

• Pipeline State Bloat: Highly complex parallel loops or deeply nested loops deeply exhaust the Master JVM memory because it aggressively tracks execution state continuously.
• Build History: Aggressively immense amounts of un-rotated build history metadata loading heavily into the GUI crashes the JVM fundamentally.

*Fix:* You must mandate the Discard Old Builds plugin securely, drastically simplify the Groovy logic, ensure strictly NO massive parsing happens on the Master explicitly via @NonCPS, and aggressively rotate the JVM garbage collector tuning.