> Currently, ARM is the only major vendor with support for TBI
is not true. Intel and AMD both have variants of TBI on their chips, called Linear Address Masking and Upper Address Ignore respectively. It's a bit of a mess, unfortunately, with both masking off different bits from the top of the address (and different bits than ARM TBI does), but it does exist.
Java has been using (or at least had the ability to use) the upper bits for concurrent mark and sweep for a decade - to implement write barriers on objects that are still in the process of being manipulated.
An idea Cliff Click first employed while at Azul and has now made it back into Hotspot.
The problem is, those addresses are completely interchangeable, nothing stops e.g. malloc() from allocating addresses somewhere around the very top of the legal addresses instead from starting near the .data's end. In fact, it seems that mmap(3) in general does pretty much that by default, so reusing address's top-bits is inherently unreliable: you don't know how much of those are actually unused which is precisely the reason why x64 made addresses effectively signed-extended integers.
You opt-in to any of the top byte masking schemes via prctl on Linux. It's fully forward compatible, in that programs that don't enable it will continue to work like normal. Additionally, Linux won't map memory at addresses higher than 2*48 by default either because non-hardware accelerated top bits pointer tagging would have the same problem. I don't think either of your complaints are valid here.
is not true. Intel and AMD both have variants of TBI on their chips, called Linear Address Masking and Upper Address Ignore respectively. It's a bit of a mess, unfortunately, with both masking off different bits from the top of the address (and different bits than ARM TBI does), but it does exist.