[aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15

[Andrew Haley]

On 06/14/2018 10:44 AM, Severin Gehwolf wrote:
> On Thu, 2018-06-14 at 10:18 +0100, Andrew Haley wrote:
>
>> When it was first proposed to use a different repo for
>> Shenandoah HotSpot the idea was that customers not using Shenandoah
>> would be using a non-Shenandoah HotSpot.  The Java launcher would only
>> load the Shenandoah libjvm.so when needed.  But as we aren't doing
>> that (are we?) there's no point.
> 
> Interesting. That is news to me. First, we aren't doing that currently.
> Second, in order to implement this we'd need to do some build and
> launcher hacks to get this working. It implies shipping two different
> libjvm.so's for aarch64 and x86_64. AFAIK, we don't do that.

It never happened because I was persuaded that it was unnecessary.
This is because none of the Shenandoah code is enabled unless
UseShenandoahGC is a command line option.  But if we're seeing
significant divergence between the Shenandoah repo and the upstream
repo in non-Shenandoah-related areas, then Houston, we have a problem.

> As to why we haven't done what you describe above (dynamic selection of
> libjvm.so based on GC config) is probably a case of got-lost-in-
> communication :-/ One person thinking that's what was meant, another
> person thinking something different.

As I said: I was persuaded it was unnecessary.  But it's only
unnecessary as long as we are utterly scrupulous about keeping the
AArch64 Shenandoah repos perfectly clean.  If Shenandoah actually
requires some fixes from upstream we can look at them to make sure
they are low risk, but that's all.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671