David Keller

> @BlobCodes Are you still working on this? If not, I'll go ahead and pick #14604 back up. I still want to work on the MR, just haven't found the...

> After familiarizing with the concept a bit more, I understand. Yeah, makes sense that we cannot use unsafe for Thread.current. 🤦 We could use it for `Thread.current` by using...

A logical follow-up to this PR would be to expose a non-clearing variant of `Pointer.malloc` in the stdlib (ex. as `Pointer.malloc_unsafe`) to speed up collection types without inner pointers.

> I'd prefer to expose something more explicit, for example just GC.malloc(size, clear: true) and __crystal_malloc(size, clear: true) and same for the atomic versions. The `__crystal_malloc*` functions are `fun`s, not...

> I'm all in for a single GC.malloc(size, *, atomic = false, clear = true) method (and an new __crystal_malloc3(size, atomic, clear) fun). Ideally, as a follow-up PR to #14679,...

> and there's a bug since #malloc_atomic currently returns uninitialized memory! https://github.com/crystal-lang/crystal/blob/835b0c7ec5945c48ddd65f856cd81338ccbe7f65/src/compiler/crystal/codegen/codegen.cr#L2174 > Then a check in #malloc_aggregate to avoid zeroing twice to fix this issue. That would fix #14677,...

Maybe we can use this issue to also discuss initializing structs and/or classes on dirty memory? Currently, even when you use a definition like `@a = uninitialized UInt8[128]` inside a...