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.

Reply via email to