jdk8u backport is brokent in 1.8.0.232.b09

[Алексей Генус]

Roman,
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
erroneously say they are aarch64 even for x86_64 builds.
2. Freezes indeed are gone. That's already good news.
3. Error with possible deadlock (from
https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still
exists
4. Original C2 issue is gone, nut new one appeared, please see
https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b


Alexey

On Wed, 13 Nov 2019 at 14:06, Roman Kennke <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
> >
>
>