Hi Dan, mmap is pretty much a given for V8. I guess the bottleneck you are looking for is base::Allocate or OS::Allocate. It should be possible to set a custom hint or flag in an os specific file or add an ifdef to get the desired constraints.
The fact that we use these 16 bits in the dispatch table is not super fundamental and we might also get rid of that at some point. However, the way you describe the illumos memory layout it seems like it would be good either way to not mmap in the space reserved for the stack. *oli On Fri, Apr 11, 2025 at 11:06 PM Dan McDonald < [email protected]> wrote: > 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 > [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/9088d250-c6f5-4641-bf22-9676344fcf2dn%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/9088d250-c6f5-4641-bf22-9676344fcf2dn%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/CAPfE2j1LhXJtcaLiosDuo62UnC086Dg6phta6XGzOD-4PDXMzA%40mail.gmail.com.
