jdk8u backport is brokent in 1.8.0.232.b09

[Roman Kennke]

Hi Alexey,

> indeed I didn't  want to use Zero VM - my fault must be misclick when I
> downloaded the build.
> Just downloaded latest snapshot and tried it out.
> 1. Just to be clear I use x86_64, not aarch64. Builds from shipilev.net
> <http://shipilev.net> erroneously say they are aarch64 even for x86_64
> builds.

Oh, wow. That's bad. We shall fix that then. And I was wondering why we
have this surge of aarch64 early adopters.

> 2. Freezes indeed are gone. That's already good news.

Great!

> 3. Error with possible deadlock (from
> https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still
> exists

I will look into this right now.

> 4. Original C2 issue is gone, nut new one appeared, please
> see https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b

We might need to see the corresponding replay file (with the same PID as
the hs_err file), and ideally the class files/JARs involved in this.

Thanks,
Roman

> Alexey
> 
> On Wed, 13 Nov 2019 at 14:06, Roman Kennke <rkennke at redhat.com
> <mailto:rkennke at redhat.com>> wrote:
> 
>     I just realized that in your latest test you used a Zero VM. This is
>     most likely not what you wanted ;-)
> 
>     Please try:
> 
>     Release build:
>     https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz
> 
>     Fastdebug build:
>     https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz
> 
>     Thanks,
>     Roman
> 
> 
>     > Hello, Shenandoah devs.
>     > I updated jdk8 from 191-b12 to 232-b09 and started to get spurious
>     freezes
>     > of my application during startup which occur pretty consistently.
>     Digging
>     > into gave me impression that is something wrong with java itself.
>     Having
>     > tried to use fastdebug build I started to get these hs_err.logs:
>     > https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180
>     > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd
>     > and another possible outcome is same as earlier - hung jvm which
>     heavily
>     > consumes CPU in GC threads with a stacktrace like that (got it
>     with perf):
>     > 32.32%  libjvm.so     [.] ShenandoahAsserts::assert_correct
>     > 16.16%  libjvm.so     [.] ShenandoahBarrierSet::write_barrier
>     > 10.10%  libjvm.so     [.] JvmtiTagMap::do_weak_oops
>     > 8.43%  libjvm.so      [.]
>     ShenandoahForwardedIsAliveClosure::do_object_b
>     > 8.25%  libjvm.so      [.]
>     > ShenandoahEvacuateUpdateRootsClosure::do_oop_work<oop>
>     > 6.71%  libjvm.so      [.] ShenandoahHeap::in_collection_set<oop>
>     > 6.16%  libjvm.so      [.] ShenandoahHeap::is_in
>     > 5.53%  libjvm.so      [.] Metaspace::contains
>     > 2.70%  libjvm.so      [.] ShenandoahHeap::heap
>     > 2.43%  libjvm.so      [.] ShenandoahHeap::kind
>     > 0.76%  libjvm.so      [.] ShenandoahHeap::heap_no_check
>     > 0.24%  [kernel]       [k] trigger_load_balance
>     > 0.14%  [kernel]       [k] system_call_fastpath
>     >
>     > Aleksey Shipilev suggested running on latest shenandoah-backport.
>     I did it
>     > and it gave me another error in 100% cases (probably unrelated to
>     original
>     > error). The log is here
>     > https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b
>     >
>     > Moving back to 1.8.0.192 helps, but maybe we can find the error here.
>     > Unfortunately I don't haven a minimal reproducible example, but
>     I'm open to
>     > any suggestions on how to make it.
>     > Do you have any thoughts about how to fix this?
>     >
>     > Alexey
>     >
>