RFR: 8256829: GNU hash style is not available on MIPS

For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be built, because linker complains: collect2: error: ld returned 1 exit status I believe it is a regression in 16, as GNU hash style was forced with [JDK-8200738](https://bugs.openjdk.java.net/browse/JDK-8200738). The way

RFR: 8256831: MIPS Zero builds fail with undefined __atomic_compare_exchange_8

If you try to build `linux-mipsel-zero-fastdebug`, this happens: I think it relates to [JDK-8253970](https://bugs.openjdk.java.net/browse/JDK-8253970) that introduced `atomic_compare_exchange` on those paths, but maybe the issue exists for longer. Various other reports for build failure

Re: RFR: 8256829: GNU hash style is not available on MIPS

On Sun, 22 Nov 2020 14:19:04 GMT, Aleksey Shipilev wrote: > For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be > built, because linker complains: > > > collect2: error: ld returned 1 exit status > > I believe it is a regression in 16, as GNU hash style was forced with

Integrated: 8256497: Zero: enable G1 and Shenandoah GCs

On Tue, 17 Nov 2020 19:02:03 GMT, Aleksey Shipilev wrote: > Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) > improvement that ditched the inline contiguous alloc use from Zero, we can > now rely on GC interface to hook the GCs properly. G1 and Shenandoah are a >

Re: RFR: 8256497: Zero: enable G1 and Shenandoah GCs [v2]

On Thu, 19 Nov 2020 09:55:04 GMT, Magnus Ihse Bursie wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into JDK-8256497-zero-g1-shenandoah >> - Remove TODO >>