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/1fa6a3d9-416a-4b49-8676-7d5b80fe52cen%40googlegroups.com.
