This is actually a really good point. Garbage collection has significant advantages for concurrency because it solves this problem so nicely; avoiding these issues in C++ often isn't just difficult for the programmer but also costs you performance. (Of course, if you generate so much garbage that the GC is running all the time, it will become a bottleneck, but the same is true of excessive allocation and deallocation even in unmanaged languages.)

But could cause a garbage collection cycle, right? If so, I think this still counts in the "not safe" category.

Generally garbage collection algorithms more sophisticated than reference counting can handle cycles just fine. Certainly this is the case for Java.

Edit: Or perhaps you mean, could cause the garbage collector to run? I don't see why that'd be an issue either.

That is what I meant. And having a garbage collector run could potentially freeze the JVM, causing a performance hit. (I mean, it is basically a global lock on the entire system, right?)

Basically, my reading of "safe" meant "would not block." A garbage collection cycle stops everything, so is effectively a block, right?

I read "safe" differently than you did; now I'm on the same page. With or without a GC, if you want to guarantee safety in that sense no matter what, you're right - you just can't allocate memory. So in the worst case running in a managed environment doesn't buy you much, but often the guarantees you need are a bit looser than that, and in that case managed memory can be really beneficial.