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

[Aleksey Shipilev]

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.

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


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

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.

-- 
Thanks,
-Aleksey