>From a different thread, Subject: "Re: [v8-dev] Sandbox js-dispatch-table code's kFreeEntryTag"
On Tuesday, April 8, 2025 at 10:45:55 AM UTC-4 Dan McDonald wrote: On Tuesday, April 8, 2025 at 2:58:37 AM UTC-4 *oli wrote: <SNIP!> AIX ran into the same issue. There is currently a CL in review to address it in their case: https://chromium-review.googlesource.com/c/v8/v8/+/6320599 . Maybe you can try that one and comment if it works for illumos. If it doesn't it would be good if you can directly work with them on that CL to find a solution that works for both OSs. I'm looking at it now, and will have things to say, thank you! After much spewage in the Gerrit (sorry about that *oli), I've come to the conclusion that the big problem, and it might not just affect the dispatch table, is that V8, or perhaps its users (I went down this rabbit hole because of Node and its under-review import of V8 13.6) seem to assume the upper 16 bits in a 64-bit pointer are always 0. As I mentioned (somewhat incorrectly) earlier: 0xfffffc7fffe00000 is the highest allowable virtual address in an illumos process. Our stack starts up there, and along with mmap() segments they both work their way down. Our heap starts from much lower and works it way up. There is a Virtual Address Hole of disallowed space between them. The low end of the hole is 0x800000000000 (47bits of non-hole space below it), the high end is 0xffff800000000000. mmap() calls without an address hint can place anywhere outside the VA hole.. Oracle Solaris, like illumos, descended from Sun Solaris => OpenSolaris, likely has this issue as well. There are two ways to approach this problem. The first is to have the OS provide a runtime environment where the top 16 bits of virtual address space are always 0. The second is to figure out how to get V8 to not allocate/mmap/etc. Our va_hole low boundary of 0x800000000000 (for internal-to-us reasons it'll actually be no allocations above 0x7fffc0000000; i.e. 1GiB shy) should do. For illumos this moment, providing that runtime environment is a global kernel-start-time tunable. This is unacceptable for a number of reasons, and providing a per-process solution is something we're investigating. I'll note Oracle Solaris has a link-time mapfile to present a low 47-bits space. I'm not sure if illumos will solve it the same way, but when we do we'll let folks know. Meanwhile I do have test environments with this global tunable set and at least with Node I'm getting far enough along where the Node tests are passing/mostly-passing. I post this letter to ask if there's any mechanisms V8 uses that I can attempt to exploit so an OS-level solution for making sure allocated space by V8 stays within the assumption about the high 16 bits being masked out? Perhaps in platform-solaris.cc? (I'll ask about splitting Oracle Solaris and illumos (much) later.) Thanks, Dan -- -- 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/9088d250-c6f5-4641-bf22-9676344fcf2dn%40googlegroups.com.
