Hi Dan, thanks for reporting the issue here. Please refer to this comment https://github.com/v8/v8/blob/main/src/sandbox/js-dispatch-table.h#L110 to understand how the JSDispatch table uses an ad-hoc compression of this particular pointer to recycle 16 of its bits for other purposes. Without digging in the code myself I cannot help you with a comprehensive list of what we assume about pointers in general.
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. Best, *oli On Mon, Apr 7, 2025 at 3:55 PM Dan McDonald < [email protected]> wrote: > On Monday, April 7, 2025 at 4:53:00 AM UTC-4 Jakob Kummerow wrote: > > > No, that code is fine. It is entirely intentional to not have a collision > between the top 16 bits in the kFreeEntryTag and the lower 32-bits payload. > > > Okay. This is good to know. > > > I may be missing something, and am glad to be educated,. To my eyes, > either this code did not consider getting pointers with the high-16-bits > set to non-zero values, > > > Yes, that code is quite clearly written for OSs where the upper 16 bits of > a 64-bit pointer are always zero. > > > Not entirely clear to the newbie reader, which is why I was here. :) > > Is there clear documentation of what v8 expects out of a pointer? If not, > I'd be happy to help write/edit one so future newbies don't stumble into > the weeds like I have. > > > For other OSs this will need adaptation. I don't have a specific > suggestion, and am not planning to work on it. If you want to work on a > patch yourself, please keep in mind to make it as non-intrusive as > possible: since such OSs are officially unsupported, we wouldn't want to > pay a large code complexity price for them. > > > I wouldn't mind. I might keep it in Node for starters since that how I > found all this out. Before I would attempt something, however,. I would > like to know V8's assumptions about pointers. If documentation exists, > please point me (pun intended) at it. If no such documentation exists, or > only exists in scattered form, I could assist, with the help of a > full-time-V8-er, to create some. An OS provider may their own assumptions > about pointers, and knowing where they cross-purposes with V8 up front > would save a lot future hassle. > > -- > -- > 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/d4e7cc3f-7e7c-454a-88c9-361e91cd794bn%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/d4e7cc3f-7e7c-454a-88c9-361e91cd794bn%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/CAPfE2j0AZYUwYhktR-D%2Bi-1AkuowryjFSASpNqypkxFZkorjCA%40mail.gmail.com.
