* The even integer numbers are pointers.
* The odd integers represent fixnums (small integers) (n <---> 2*n+1).
With this representation the calculations with fixnums are quite fast because they don't need unboxing.
[0]: https://github.com/ruby/ruby/blob/cbd1f2571af6bf93d5c4d4c25b...
[1]: https://github.com/ruby/ruby/blob/cbd1f2571af6bf93d5c4d4c25b...
Edit: It is assumed that pointers will be at least 16-bit aligned and thus, an odd-value pointer is never valid. So they can safely re-use half of the value space for integer values. So, you get fast integer arithmetic, but you don't get the fast floating point math like you do with NaN-boxing.
[2]: https://github.com/ruby/ruby/blob/cbd1f2571af6bf93d5c4d4c25b...
The sentinel pointers work like this: the zero page is assumed to never point to a valid Ruby object (NULL through NULL+PAGE_SIZE-1), so they just use some otherwise "pointer" shaped numbers in that range as special values (nil, true, false).
As for performance penalty, unaligned memory accesses are (at least potentially) slower than aligned on almost any architecture. On some architectures they are simple not implemented in hardware and cause an exception (which includes SPARC and essentially anything purporting to be any kind of RISC)
As for SPARC: SPARC actually even has hardware support for similar tagging mechanism: TADDcc and related instructions. Idea is that integers are taged by having two LSB's set to 00. These additional instructions do arithmetic as normal, but also set overflow flag (and optionally cause exception) when any of the operands have tag different from 00. Thus code can do the common case of fixnum arithmetic in one instruction (and possibly OF check) and only when overflow is detected fallback to slower codepath that handles fixnum->bignum overflows and non-fixnum datatypes.