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

[Severin Gehwolf]

On Thu, 2018-06-14 at 10:18 +0100, Andrew Haley wrote:
> On 06/14/2018 09:36 AM, Severin Gehwolf wrote:
> > On Thu, 2018-06-14 at 09:22 +0100, Andrew Haley wrote:
> > > On 06/14/2018 09:21 AM, Severin Gehwolf wrote:
> > > > On Thu, 2018-06-14 at 09:10 +0100, Andrew Haley wrote:
> > > > > > The way we build our RPMs is that we use the
> > > > > > aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and
> > > > > > aarch64/jdk8u on all other architectures.
> > > > > 
> > > > > Why do we still do that?
> > > > 
> > > > Because shenandoah only works on aarch64 and x86_64. 
> > > > 
> > > > -XX:+UseShenandoahGC on unsupported arches would need to get disabled
> > > > at runtime.
> > > 
> > > Yes.  But that doesn't explain why we use different repos.
> > 
> > I'm confused. That's the approach we took to get Shenandoah support on
> > aarch64 and x86_64. How do you suggest to change it? Use
> > aarch64/shenandoah-jdk8u (the entire forest, not just hotspot) for all
> > arches?
> 
> What is the advantage of now using a different repo for the minority
> architectures?

I suppose only that non-shendandoah arches get hotspot without added C2
code for shenandoah. There might be some other things I'm missing...

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

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.

Thanks,
Severin