RFR: 8302780: Add support for vectorized arraycopy GC barriers [v8]

Erik Österlund eosterlund at openjdk.org
Fri Mar 3 10:45:17 UTC 2023


On Thu, 2 Mar 2023 10:02:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
>> I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
>> Please consider these style changes.
>> 
>> In my opinion, the (very much needed) changes you suggest are outside the scope of this PR, which is about lifting the memory accesses, in their existing form, to a barrier API-level. Conflating this with your suggested changes would make it harder to review this PR, which is sufficiently complex in its current form. I totally agree that your suggestions would improve readability and maintainability, but couldn't we apply them in a follow-up RFE?
>
>> > All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
>> > I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
>> > Please consider these style changes.
>> 
>> In my opinion, the (very much needed) changes you suggest are outside the scope of this PR, which is about lifting the memory accesses, in their existing form, to a barrier API-level. Conflating this with your suggested changes would make it harder to review this PR, which is sufficiently complex in its current form. I totally agree that your suggestions would improve readability and maintainability, but couldn't we apply them in a follow-up RFE?
> 
> I disagree in every way. The added complexity, which is fixed so it no longer matters, made it near-impossible for me to reason about this PR.  And, as John Rose put it, like any good carpenter we should clean up as we work.

Thanks for the review @theRealAph! And thanks also to @robcasloz, @albertnetymk and @RealFYang.

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

PR: https://git.openjdk.org/jdk/pull/12670


More information about the hotspot-dev mailing list