I believe any speculative execution, including starting to process both paths of a conditional branch in advance, is open to spectre if you don't clean up all internal traces of the path not taken before returning control to the next instruction. It may be that it's messier or more time-consuming to clean up after transactional execution because there could be a lot more speculative execution before it fails.
On 2022-04-06 7:46 p.m., Ngan, Robert (DXC Luxoft) wrote:
Hmmm, you mention "speculative execution". Maybe that make it vulnerable to meltdown/spectre type attacks.
Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: [email protected] Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -----Original Message-----
From: IBM Mainframe Assembler List<[email protected]> On Behalf Of Dan Greiner Sent: Wednesday, April 6, 2022 17:47 To:[email protected] Subject: Re: Removal of transactional execution facility 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.
