RFR: 8349713: [leyden] Memory map the cached code file [v2]

[Ioi Lam]

On Mon, 10 Feb 2025 15:35:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Good. Until, as we discussed, cached code (and its data) will be part of CDS archive file.
> 
> Yes, that would make this whole thing no-op. CDS mmap-s the archive already.
> 
> > How CDS handles `mmap` on windows?
> 
> Windows can still memory-map the file through its Windows APIs. But I _vaguely_ recollect some corner cases that @iklam fights every so often in CDS. Something with remapping or so? See `MetaspaceShared::use_windows_memory_mapping`, for example. I don't think it is wise to spend time dealing with those corner cases in current Leyden prototype, let it be part of whole CDS archive first.

With the Windows APIs used by HotSpot today (VirtualAlloc and MapViewOfFile), we can't map a file into a reserved region. If we just want to mmap the SCCache into non-reserved, random location that's picked by the OS, we can already do that today with HotSpot.

In some cases, CDS wants to mmap into reserved regions. On Windows, we end up not mapping with MapViewOfFile, but simply reading the entire CDS file into reserved memory.

I think with this new API [MapViewOfFile3](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffile3), we can map into a reserved region. This would be useful if, for example, we want the SCCache to be immediately next to CDS, so that the AOT code can use relative addressing for metadata pointers (InstanceKlass*, etc).

-------------

PR Comment: https://git.openjdk.org/leyden/pull/34#issuecomment-2648703580