RFR: 8342601: AArch64: Micro-optimize bit shift in copy_memory

[Aleksey Shipilev]

On Mon, 21 Oct 2024 11:25:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Looking at this differently: if I wrote the `copy_memory` stub from scratch today, would I do this optimization? Answering personally, I probably would.
> 
> I wonder if that's too low a bar for whether we should change it now, though. If we adopt "would I have done it this way, first time around?" as an appropriate threshold for a change, it gives permission for endless churn with tiny issues. 

I don't think about this in slippery slope terms. There is always a cost/benefit calculation for every change. Contributors' costs are not zero (see the testing that goes into these), which is a part of back-pressure against doing this often. Reviewers costs are not zero either, but that cost is in control of reviewers -- _that's us!_ -- themselves. In that sense, tiny patches become a problem only when we collectively spend disproportionate amount of time on them, like in this PR. I advocate for taking low-benefit patches quickly, without accidentally inflating their costs.

With regards for post-integration touchups, I think the reverse policy would be worse, if not straight-up chilling: we will have to be extra-stringent on getting every little detail absolutely, un-changeably right during every review, if the amendments would not pass the contribution bar. I don't believe this is the outcome we want either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21589#issuecomment-2426608041