Repeat "...And for global variables of managed types, no additional code is generated for zeroing". The compiler (not the OS) knows that it is not required to zeroed them.
What about stack? Stackspace is dirty by default.What about longstrings that are part of a class or record? What about code where the initialization is overridden (e.g. newinstance is virtual)? You are making assumptions that are nor always true.
And it is not always the compiler, but the runtime library that initializes memory through InitInstance, which in turn can be skipped in newinstance.
This is only the scenario for classes. With managed objects and managed records - that are now supported - it is even more dangerous to rely on such an assumption: e.g. New() does getmem (dirty), not allocmem(clean).
You should assume *nothing* about initialization and even ignore some current behavior that you happen to think to know about the current implementation.
BTW: This is also true for Delphi: at least before XE2 and higher, compiling.debugging in the IDE cleans all heap memory, but not when running a program outside the IDE: behavior is not to clean the heap unless initinstance (which happens to AllocMem..implementation detail)is called, and that is not guaranteed..
The compiler (not the OS) knows that it is not required to zeroed them.
Is therefor nonsense. This is a programmer's task, not a compiler's task. Class fields or not: they can not be assumed to be clean.