The following code is for the Windows version of os::pd_remap_memory():

// Remap a block of memory.
char* os::pd_remap_memory(int fd, const char* file_name, size_t file_offset,
                       char *addr, size_t bytes, bool read_only,
                       bool allow_exec) {
  // This OS does not allow existing memory maps to be remapped so we
  // have to unmap the memory before we remap it.
  if (!os::unmap_memory(addr, bytes)) {
    return NULL;
  }

  // There is a very small theoretical window between the unmap_memory()
  // call above and the map_memory() call below where a thread in native
  // code may be able to access an address that is no longer mapped.

  return os::map_memory(fd, file_name, file_offset, addr, bytes,
           read_only, allow_exec);
}

JDK-8087153 showed that this window is not just theoretical. It can in fact happened. For JDK-8087153, this code path became more heavily exercised because the recently introduced changes for JDK-8054386. It resulted in a region being access by another thread between the above unmap an map calls. JDK-8087153 was resolved by making additional improvements to JDK-8054386 so it no longer results in the above code path being heavily exercised (it is exercised no more than before JDK-8054386). However, the potential for it to be triggered is still there.