Seems like this will soon be a problem for Linux too. My /proc/cpuinfo says:
address sizes : 52 bits physical, 57 bits virtual so it looks like we can't assume the high 16 bits are zero for much longer. On Tuesday, April 22, 2025 at 5:21:16 PM UTC+2 kebesoftwar...@gmail.com wrote: > Per the nearly-approved AIX commit conversation ( > https://chromium-review.googlesource.com/c/v8/v8/+/6320599 ), I would > like to address V8's mishandling of illumos/amd64 VA48 available address > space. The problem is rather straightforward: illumos amd64 processes > have their 48-bit available VA space split into two parts. > > Per the original amd64/x64 4-level paging spec: the low 47 bits of address > space: 0x0 -> 0x00007fffffffffff are available, AND SO IS the high 47 bits > of available address space: 0xffff800000000000 -> 0xffffffffffffffff. > Notwithstanding carve-outs toward the extremes of the 64-bit address space > (i.e. not too close to 0 or to 0xffffffffffffffff), memory mappings can > come from either of those ranges. > > For pointer-compression that shifts 16 bits to the left, the easy thing to > do is to check the highest-order compressed-pointer bit, and fill the top > 16 with 1s upon decompression. Decompression is done in CodeStubAssembler > ::LoadCodeObjectFromJSDispatchTable(), and while I had my first-attempt > implementation picked-apart as part of my experiments with Node, the idea > is sound. > > Also, the choice made in the JS Dispatch Table to mark a free pointer with > 0xffff in the top 16 bits will not work in an amd64 address space using all > of the available VA space, because half of it lives in address space > starting with 0xffff. A change of marking bits (I used 0xfeed in the > first-attempt) and better clearing/checking (using logical-and) solves this. > > The assumption of only-low-47-bits of virtual address space runs up > against two problems. The first is expanded available virtual address > space beyond 0x0000800000000000. The aforementioned IBM/AIX changes hint > at this possibility: All 48 lower bits are available with a fixed non-zero > 16-bit prefix. The second is that at least for amd64, address space will > appear in both the high-end and the low-end of the 64-bit address space. > > Already available in some hardware is VA57, which resembles the > aforementioned VA48 except that the low available space grows to 0x0 -> > 0x007fffffffffffff, and the high available space grows down to cover > 0xff80000000000000 -> 0xffffffffffffffff. Operating systems may offer the > entirety of both ends of VA57 to a process. > > I would like to help correct this in V8 so its downstreams, especially > Node, can work properly in environments that offer full address space to > processes. I'm reading up on https://v8.dev/docs/contribute , and please > consider this email my following of, "Ask on V8’s mailing list for > guidance". > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/1ca103a0-8623-430a-83f4-58ee712b329en%40googlegroups.com.
