[jdk21u-dev] RFR: 8320379: C2: Sort spilling/unspilling sequence for better ld/st merging into ldp/stp on AArch64

[Andrew Haley]

On 6/7/24 18:09, Aleksey Shipilev wrote:
> On Fri, 7 Jun 2024 16:45:53 GMT, Andrew Haley <aph at openjdk.org> wrote:
> 
>> I understand that, but wouldn't that apply to all minor performance improvements? And wouldn't the direct consequence of following that principle to its conclusion be that if anyone wanted a stable release, too bad: there isn't a stable release? I totally get why this low-risk fix is a good thing, but...
> 
> Well, we don't have to drive that principle to conclusion. There are always changes in releases, and I believe that JDK 21 is the most fluid one at the moment, while JDK 8 is the most rigid one. It does not mean we don't do JDK 8 changes at all, though, so even that rigidity is not absolute.

OK, fine. I was just checking. The "thousand paper cuts" argument made me think of "a thousand backports." :-)

> There is always cost-benefit calculation in every backport. The little cost for backporting, testing, and future tracking is already taken by @pengxiaolong. We reap a little benefit for it in exchange. We do this in release that is an enticing migration target for LTS-tracking projects, giving migration a little more edge. What's not to like?

So if there's a cost-benefit argument to be made, then feature backport PRs (as opposed to bug fixes) should at least make the argument. It is not obvious to me where the cost-benefit argument lands in this case.

Bug fixes are different, I think.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671