There are potentially several places in Hotspot where we do multiple non-atomic memory allocations that assume portions of the address space will remain unallocated in between the non-atomic calls. For example, in order to split a memory region on Windows, we must de-allocate the region completely then re-allocate two separate new regions in the same place in the address space. It's possible for another intervening thread to allocate in that region between the de-allocate/re-allocate operations. In most of these cases the VM is running single threaded at this point, but it's still possible in rare cases that a native application embedding the VM (such as IE/Mozilla) may be allocating in a non-Java thread.

Known potential problem areas in the existing code are listed in the comments section.

In addition, there are surely still other unknown problem spots. It's likely that some kind of stress testing and/or fault injection would be valuable here to uncover these additional areas.