pgalloc: skip host holes during checkpoint

[shayonj]

I was looking into optimizing checkpoint and restore performance. In doing so, I found that a fair amount of checkpoint CPU was spent in MemoryFile.SaveTo, where it reads every possibly committed page to find zeroes even when the sparse host backing file already proves that a range reads as zero. Runtime heaps can leave large holes after startup or garbage collection, so this scan can become a material part of checkpoint time.

I tried using SEEK_DATA and SEEK_HOLE to skip those known host holes. The extent path runs only when fstat proves that more than one eighth of the accounted memory is unbacked, and it still byte-scans every reported data extent. This adds extent queries to qualifying sparse checkpoints, while dense files, disk-backed memory, and hosts where extent discovery fails keep the existing page scan. I left the image format and restore path unchanged, and the change adds no option or application hot-path work.

In the end-to-end test I did with a Hono application on Bun 1.4 and a Spring Boot application on OpenJDK 21, each application warmed its router, JSON serialization, and small state map with 2,000 validated requests before checkpoint. The applications used no synthetic heap allocation and validated another request after restore. Hono used HTTP over a Unix socket, while Spring used MockMvc because the direct-containerd harness has no network device. I ran 20 alternating pairs per application.

Application	Checkpoint time	Checkpoint cgroup CPU
Bun and Hono	78 ms to 41 ms, dropped by 47%	118 ms to 73 ms, dropped by 35%
Java and Spring Boot	101 ms to 75 ms, dropped by 25%	203 ms to 163 ms, dropped by 22%

Restore timing, image size, memory use, and faults varied between launches without a consistent candidate effect. Dense or retained heaps continue to use the existing scan.