Yeah, we are not clinging to that design. It really should be a normal compressed pointer. Then we'd have space for a separate mark bit and argument count like on 32 bit architectures. Last I checked there were some technical issues with getting the correct base to uncompress the pointer and it's also kinda performance sensitive. That's why nobody has addressed it so far.
That said, I don't think we have to worry about user space pointers in that range according to https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt . *oli On Mon, Aug 4, 2025 at 1:04 PM Erik Corry <[email protected]> wrote: > 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 [email protected] > 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 > [email protected] > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/v8-dev/1ca103a0-8623-430a-83f4-58ee712b329en%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/1ca103a0-8623-430a-83f4-58ee712b329en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAPfE2j2Z%2BZOmz2YH2DUAO9axJcc1XhKECCDjVtTK8gwyHRDESQ%40mail.gmail.com.
