[aarch64-port-dev ] [11u] RFR 8228400: Remove built-in AArch64 simulator

[Andrew Haley]

On 8/1/19 9:17 AM, Aleksey Shipilev wrote:
> On 8/1/19 2:41 AM, Andrew Haley wrote:
>> On 7/31/19 7:32 PM, Aleksey Shipilev wrote:
>>> I thought we would remove it in 8u-aarch64, in preparation for
>>> eventual upstreaming. It that case, it makes sense to have all
>>> releases share the same code shape to simplify future backporting.
>>> Simulator is already removed in 14, and assuming we are doing it in
>>> 8u-aarch64, 11u would be the only release left with the built-in
>>> simulator.
>>
>> I see. So, your proposal to do this in order to minimize the size of
>> the aarch64 patch to be imported into 8u? 
> 
> Yes. That is the whole reason for my recent aarch64-port work.

OK.

>> I didn't remove the builtin sim when the AArch64 port was
>> contributed to mainline because it seemed to me to be a pointless
>> change, and it still does. It's not simply laziness, I considered
>> doing this and rejected it. I don't think it aids maintainability.

> I disagree.

Yes, I get that. :-)

> You might be affected by close familiarity with that code. However,
> I have actually read the entire 8u-aarch64-vs-8u-upstream webrev,
> and having dead code there does not improve that experience. Neither
> does it improve backporting, as I see review threads asking "what do
> we do with BUILTIN_SIM paths" with aarch64 maintainers having to
> step in and telling to ignore those paths. If those paths are that
> irrelevant, they have to be removed to eliminate confusion. That is
> what "aiding maintainability" is.

It's one aspect of maintainability. Clean history is another.

>> However, there is a point I accept: one could argue that in a sense
>> the 8u backport is "new", so perhaps a cleanup is justified for that
>> reason.
> 
> Yes, so as I said, that would leave 11u in the awkward position of
> being different with both 8u-aarch64 and jdk14+. Shenandoah
> experience tells us the effort taken to maintain similar code shape
> pays back for future backports: most backports would apply cleanly
> then, requiring no additional review.

Sure, but this means that code cleanups always have this disadvantage,
that of making backports harder. One black mark against cleanups, I
guess.

> Anyway, I have formally requested the backport of JDK-8228400 with
> jdk11u-fix-request. If you still feel it should not be in 11u,
> please formally reject it with jdk11u-fix-no. I would then give up
> here, and move on backporting this removal to 8u-aarch64.

I'll think some more. I can see both sides of this, and I guess the
builtin sim is a special case. I am certainly not going to treat this
as a precedent for future cleanups.

-- 
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