Read pages through a memory map of their segment

[venkat1701]

First step toward keeping the raw page cache off the Java heap. The server binary is built with --gc=serial, and right now every page that misses NodeCache is read with pread into one or two new heap buffers. This PR maps segment files read-only and reads pages out of the map instead, so the raw bytes sit in the OS page cache. A follow-up on top of #69 will shrink the decoded cache and rename it node_cache_mb.

What changed

• SegmentFile keeps a read-only map of the file. If the map covers the image, read copies exactly 80 + payloadLength bytes from it into a heap array. No system call.
• A sealed segment is remapped as soon as a read needs bytes past the map. The active segment is remapped only after it has grown 4 MiB past it; until then the newest pages are read with pread. PageStore seals a segment when it rolls, and seals everything but the active segment on open.
• Maps are made in Arena.ofAuto(). Closing an Arena.ofShared() in a native image needs -H:+SharedArenaSupport, which is experimental. An automatic arena also keeps the map valid for a thread that is mid-copy when compaction deletes the segment. Segment files are never truncated, so a map can't point past the end of its file.
• Both paths now return exactly one image, read-only. The pread path used to return the whole 4 KiB first buffer when the image was smaller.

Why it copies instead of decoding from the map

ByteCursor reads byte by byte through MemorySegment. In a microbenchmark, decoding varlongs ran at 4.9 ns each from a map and 6.6 ns from a heap array when each was the only kind the JVM saw. Mixed in one JVM, both went to 15-35 ns. In the engine the WAL, catalog and feed always decode from heap arrays, so decoding pages straight from the map would slow down every decoder. Copying the page first kept decoding at 4.8 ns.

Numbers

Measured on a loaded laptop (load average 20-33), so only the direct measurements are worth quoting.

	pread (main)	mapped
PageStore.read, every page of a 24,000-page store once after reopen	7.8-11.3 us	2.6-3.7 us
same, second pass	6.7-10.4 us	1.5-3.2 us
heap allocated per read.members op with a 32 MB node cache	16.0 KB	12.5 KB

The full comparison benchmark swung 0.3x to 3x between identical runs at that load, so I'm not quoting its throughput. Cold incidence reads in it came out lower in some pairs, but the store-level measurement above doesn't show that, and I couldn't separate it from the noise. It needs a rerun on a quiet machine.

Testing

• New PageStoreTest: 16,000 pages of random sizes written and read back while segments fill, roll and reopen; reads are read-only; finished segments get mapped, and the growing one only after 4 MiB. Breaking the mapping, the seal on roll or the growth remap each fails a test.
• Full suite: 115 tests pass.
• Built the native server from this branch, ran hstore bench, then hstore check on all nine databases it produced: about 130,000 pages verified through mapped reads. check on the largest took 2.3-2.9 s against 2.5-3.4 s with the 0.1.0 binary.

Interaction with the open stack

#74 copies relocated leaves by writing a new page id into the buffer that read returned. With reads now read-only, that call has to copy the page first. Whichever of the two merges second needs that small change, and I'll do it when rebasing.