It should be unnecessary to allocate untraced data in M3 modules (though we still do this in a few modules). Note that safe M3 modules cannot deallocate these structures with DISPOSE, thereby consuming system memory without being able reallocate it to another M3 type.
Another critical point against untraced memory is that for memory safety reasons it cannot be deallocated once passed to an untrusted extension. C and UNSAFE m3 code in our system are considered as trusted modules. Therefore, passing an untraced memory reference to these modules is a safe operations as long as it is not deallocated and subsequently used by the potentially untrusted caller. Further, the use of untraced memory even in trusted modules invites the possibility of memory leaks and unsafe access, and should be discouraged.
The bottom line is that the allocation of untraced memory is a potential source of memory leaks, and the deallocation of it is a source of breaching memory safety required by the system.
Disallow the allocation of untraced memory in safe modules. This can be statically enforced by adding the ``NOT Module.IsSafe()'' requirement to the M3 compiler builtin NEW operator for untraced memory. A drastic approach is to disable the allocation of untraced memory in m3 modules, and eventually eliminating the UNTRACED REF type from the language. There is no need for the memory dichotomy introduced by M3, especially when the type header of traced memory can placed out-of-line.