1. 14

Note: If you get a “Could not find article” message, please try to reload the page. Sorry for the inconvenience.

  1.  

  2. 8

    Pointers actually only use the lower 48 bits out of their total 64

    Whenever NaN-boxing comes up this gets repeated. While it’s technically true now for some architectures, it’s not true for all architectures and it isn’t guaranteed to be true in the future. x86_64 mandates that processors support 48-bit virtual addresses, but allows expansion up to 52-bits in the future. Other 64-bit architectures like POWER (IIRC) reserve all 64 bits now, and an operating system could theoretically put things in virtual memory in a way that would make use of all of those bits (single-level-store systems like to use the entire address space, for example).

    Note that I say this not to be nitpicky: this is a good article and NaN boxing is a very useful technique. It just reminds me of times past when not all pointer bits would be used and so devs felt like they could hijack those bits for their own purposes and then there had to be a painful transition when the architecture needed to make use of said bits (e.g. the Macintosh’s conversion from 24-bit addressing to 32-bit addressing).

    EDIT: This was addressed in the article, my bad.

    1. 5

      Thanks for your feedback!

      You’re right, it is indeed an assumption about current hardware. I mentioned this briefly in the article:

      Note: This is an assumption about current hardware and architectures. It’s not guaranteed to always be the case so keep that in mind if you’re writing code that’s supposed to last for a very long time (decades+).

      1. 4

        Hah, my bad. I spoke before I finished reading and while multitasking. Consider me corrected. :)

        1. 1

          NaN boxing already doesn’t work for arm64e authenticated pointers, as the authentication codes are placed in the high bits. Obviously not everything is authenticated, but this does limit what you can place in a nanboxed union

        2. 3

          Also, IIRC amd64 uses “canonical addresses” that keep the address space able to grow up and down. You’ll probably have a bad day using those bits even today.

          1. 2

            The lower 47 bits of a pointer on amd64 are always significant. The upper 17 bits are also significant, but with an added wrinkle: they must all be the same as each other. So that’s 17 actual bits that carry 1 bit of information; they act together as 1 bit. This diagram on wikipedia shows it well.

            So, you need a boxing/unboxing operation; you can’t just keep the lower 48 bits of a pointer. But 48 bits is all you need to recover the original pointer; you check the 48th bit and set the upper 16 bits according to it.


            Note also that, as WP mentions, higher half kernels will reserve the upper half of the address space for the kernel and the lower half for userspace; if you can ensure that you’re running on such a kernel, you can avoid needing to check/mask the upper bits.

            1. 1

              Same is true on arm64 - at least apple’s ones - all user space pointers are high-0, and kernel are high-1. Whether there’s a reason beyond debuggability I do not know.

              1. 1

                Arm64—at least apple’s ones—are transitioning to use the high bits for authentication.

                1. 1

                  I mentioned that elsewhere, they’ve been that way for at least a year at this point (the passage of time has lost all meaning so I can’t recall if it’s one year or two) :)

                  however an actual address are either all 0s or all 1s, and it’s an invalid address if they’re not. The result of authenticating a signed pointer will be either a pointer with all the top bits being the same, or an error. On the A series chips an error is indicated by having a pointer that does not have all high bits being the same. The result is that any attempt to use an incorrectly signed/authenticated pointer will produce an invalid pointer that will trigger a fault when used.

          2. 3

            The expansion to larger address spaces has already happened: https://en.wikipedia.org/wiki/Intel_5-level_paging

            1. 1

              Interesting! Is this active by default or is this more of a “turn it on when you need it” kind of thing?

              1. 2

                My understanding is it’s supported in the hardware, and operating systems can turn it on at boot time if they decide they want to. According to a random kernel mailing list thread, if the hardware supports it and the kernel is compiled with the option enabled, on Linux the flags in /proc/cpuinfo will include la57. Details fairly scarce, which makes me believe there’s not much use of it in the wild yet, which makes sense ‘cause most people aren’t going to have more than 256 TB of memory in their computers and there’s a small but global runtime performance hit to using it. (The tree data structure that the OS and processor uses to organize memory has to get bigger and deeper, so every non-cached memory lookup has to do a little more work.)

                I’m actually not sure whether AMD processors support the extension (yet), would be interesting to find out.

            2. 1

              Please nobody use this in C code. Portability will break at some point. It’s a nice technique, interesting write-up and it’d be perfectly reasonable for a compiler to use such techniques when compiling languages with value-types/discriminated-records but if done in a C project someone will curse you in time. And if you still do it, make sure you have a good reason (an array of a zillion of them in memory) and that the fallback implementation can be trivially enabled in the code.

            3. 4

              I wrote this article to give other people an introduction to NaN-boxing. Please let me know what you think!

              1. 2

                The link seems broken at tHe moment, can you update it?

                1. 1

                  Are you getting an actual 404 or the „Cannot find article“ message? If its the latter please try and reload the page. JS isn‘t my strong point :P

                  1. 2

                    “Cannot find article”. Indeed, after reloading a couple of times it did load. Thanks!

              2. 6

                When you have eliminated the JavaScript, whatever remains must be an empty page.

                For real now, it’s 2020, enable JavaScript.

                Reading this made me a little bit angry, and I decided not to read your blog post. I think if it had said “Sorry, my site doesn’t work without Javascript enabled!” I would have whitelisted you instead.

                1. 6

                  Ditto – I understand the frustration of authors who want to use JS, but this error message is just silly. If anything, the case for keeping JS disabled by default has grown stronger over time.

                  1. 4

                    Making you angry wasn’t my goal. I’m sorry about that. I changed the message to something friendlier :)

                    1. 5

                      Why create a web page that can’t be read without using JS? For something complex I could see the need, but this is a simple blog post that could easily be served as a few KB of static HTML.

                      And it seems this mechanism is making your site slow and unreliable too. I got the error message, but then a second later it went away, then a second later the text appeared. Not a good UX…

                      1. 2

                        Why create a web page that can’t be read without using JS?

                        I have no reason to think KCreate intended to do this, but if someone wanted to cheat lobste.rs, this would be one way to do it.

                        Basically, making an article require JavaScript is a guaranteed way to get a few comments. Lobsters also counts comments as upvotes. Since there’s no “Requires JavaScript” downvote reason, requiring JavaScript will actually make your article rank higher, almost guaranteed

                        1. 4

                          That’s an exceedingly uncharitable interpretation. It’s an outstanding problem I’ve pointed out to him and he intends to remove the JS when he gets time. It’s just old code from when he first set up his website.

                          1. 2

                            Since there’s no “Requires JavaScript” downvote reason, requiring JavaScript will actually make your article rank higher, almost guaranteed

                            Users can flag the submission as “Broken link” instead of commenting.

                            I’m fine with requiring any submission here to be readable without JS - but that’s currently not a hard requirement for a submission.

                            Edit I just checked every site currently linked from the front page in w3m, and this was the only one that was not readable[1]. This gives one data point towards an informal or formal requirement that every submission should degrade gracefully to be on-topic for lobste.rs.

                            [1] the page that is visible does link to the github source now.

                        2. 4

                          Thanks - the new message is much better :)

                      2. 3

                        The excessive use of js on this site is excruciating.

                        Rather than just sending the article in response it clearly sends js to do an XHR to load the content.

                        The result is that the page is loaded blank, pauses for a while (presumably an arbitrary timeout), and then once the xhr returns replaces the content.

                        I’m guessing it also offloads the highlighting to the client side as well for good measure.

                        All of which is user hostile:

                        • many places still charge end users for data, so making multiple requests completely unnecessarily is costing them more

                        • even with my good connection the increase in page load latency is absurd

                        • doing work client side necessarily means consuming more power

                        This content is entirely static. There no reason for js to be used at all, and in this case seems to be more about saying “you have to use js in 2020” than doing anything actually useful to the end user.

                        1. 3

                          I agree! The page really sucks…. It started as a small tech demo to test out some animations and then I got lazy and turned it into my personal website.

                          Building a new website has been on my to-do list for a very long time and all the comments (valid constructive criticism) finally made me do it. It’s now 100% JS free (except some analytics) and served as static html files.

                          I’m interested in your opinion about the new version: https://leonardschuetz.ch/

                          1. 3

                            It looks very nice now (tested on Chrome for iOS)

                            1. 2

                              Thanks!

                        2. 2

                          Nice article, Leonard! I’m glad you finally got around to writing it :)