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

[Andrew Haley]

On Mon, 21 Oct 2024 12:59:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> 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'm not sure about that. Even if you were to discount the cost of the PR review process entirely, there's the long-term cost of churn in the change logs, etc. We've all done archaeology, trying to figure out why and when a change was made, and every patch costs something. I certainly would much prefer to read a cleanup patch with twenty small changes in it than twenty small patches scattered in between more significant contributions.

> I advocate for taking low-benefit patches quickly, without accidentally inflating their costs.

I think that you are at one end of the range of opinions, judging by the other comments to this post. I held a workshop session about low-benefit patches at the most recent committers' workshop, and there was a good deal of opinion, with many people advocating some pushback against then.
 
> 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.

True enough, but I don't think anyone was proposing a change to the _de facto_ current policy. @dean-long and @rose00 were raising a skeptical eyebrow about this change.

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

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