I was as surprised – no, make that shocked – to see that IBM announced the removal of transactional-execution (TX) and constrained-transactional-execution (CTX) facilities in some future Z system. During the development of the facility, it showed significant (incredible!) performance benefits in lock elision; it was also touted by the Java development team for its speculative-execution characteristics.
Having been retired for over four years now, I cannot speak to the rationale (or irrationale) for planning on the facilities' removal. One might speculate that the minimal usage of the facilities did not justify the ongoing complexity of their implementation (TX is REALLY complex). As with any new architectural feature, it takes quite a while before many ISVs and customers exploit it. Having to dual-path one's code to account for the presence or absence of such a facility only prolongs the delay in exploitation. Consider how long it takes for an OS's level-set to catch up with the ever-evolving architecture. But if TX was such a hot feature, why wasn't its exploitation by IBM's own software sufficient to justify the obvious benefits that it provided? As the announcement letter said, "In some future IBM Z hardware system family, the transactional execution and constrained transactional execution facility will no longer be supported." Perhaps this ambiguity opens the possibility to a change of heart on IBM's part if enough customers and ISVs protest loudly enough ... but I doubt it. As to Mr. Shaw's comment about "feeling kinda 'had' now" ... yeah, that's a polite way to put it.