Re: [ANN] LuaJIT x64 port sponsorship program

[Mike Pall <mikelu-1002@...>]

Florian Weimer wrote:
> I raised this on the x86_64 ABI mailing list.  The belief over there
> is that all 2**64 pointer values are valid per the ABI.  It's just
> that *addresses of objects* will always fall in the 2**48 sub-range.

Well, C99 makes no such distinction. It ties the definition of a
valid pointer to where it can legally point to. But the x86_64 ABI
is wedded to POSIX, anyway. Which adds another bunch of rules to
the mix. I guess we could argue about standards ad infinitum
without getting anywhere ...

What really counts is commonly accepted usage. So, while I can buy
the need for MAP_FAILED et al, any reasonable Lua/C binding ought
to convert this to nil or throw an error. And using lightuserdata
for 64 bit integers is more like a hack or a workaround, which
isn't even portable to 32 bit CPUs. Most other uses probably *do*
pass valid pointers to objects.

> Lua could do something similar to Objective Caml here.  To certain
> routines in their VM, you may only pass valid pointers to objects you
> created outside the VM (or pointing to somewhere in those objects).
> All other pointers can be mutilated by the GC.  But adopting this
> would change the Lua API.

A way to pin some pointers (interior and/or exterior) would at
least pave the way for a moving GC. That would be the prerequisite
for a fast bump allocator and a generational GC. Something like
lua_pin_touserdata() and lua_pin_tolstring() might work. It would
be a no-op right now, since the current guarantees for pointer
stability are more restrictive.

> Another option would be to box light userdata if it's outside the
> 2**48 range.

Surely this can be done. But that loses the "light" part of it.
And it drives up the complexity: you now have two internal types
that are really the same. All equality checks and the table hash
need to use the values and not the pointers, unless you intern
all of the heavy-lightuserdatas.

Comparing the complexity cost vs. the benefit, I'd think this is
not a good deal. For now I'll apply YAGNI here.

And to come back to the topic of the thread: if any of the
sponsors really need it, I'll do it. But from what I know about
their use cases, they use full userdata and would rather prefer
that I focus on completing the x64 port.

--Mike